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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document is part of a series of documents that specify charging functionality and charging management in 
3GPP networks. The GSM/UMTS core network charging architecture and principles are specified in 3GPP TS 32.240 
[1], which provides an umbrella for other charging management documents that specify 

• the content of the CDRs per domain and subsystem (offline charging); 

• the content of real-time charging messages per domain / subsystem (online charging); 

• the functionality of online and offline charging for those domains and subsystems; 

• the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or 
charging events). 

The complete document structure for these TSs is defined in 3GPP TS 32.240 [1]. 

The present document covers all internal aspects of the Online Charging System (OCS). The document contains the 
architecture and functions of the OCS logical components and thereby derives the functionality of the OCS interfaces. 
A detailed specification of interfaces between the logical OCS components is also included. The functionality of the 
OCS, as described in the present document, applies to all charging domains (bearer, session and service). 

The interfaces connecting to the OCS (e.g. Ro, CAP) are out of the scope of the present document. 

NOTE: In the current release the present document is limited to the interface between the charging function and the 
Rating Function, namely Re. 

All terms, definitions and abbreviations used in the present document, that are common across 3GPP TSs, are defined in 
3GPP TR 21.905 [100]. Those that are common across charging management in 3GPP domains, services, or subsystems 
are provided in the umbrella document 3GPP TS 32.240 [1]. Finally, those items that are specific to the present 
document are defined exclusively in the present document. 

Furthermore, requirements that govern the charging work are specified in 3GPP TS 22.1 15 [101]. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
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a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 
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Architecture and Principles". 

[2]-[10] Void. 

[II] 3GPP TS 32.251: "Telecommunication management; Charging management; Packet Switched 
(PS) domain charging". 

[12] 3GPP TS 32.252: "Telecommunication management; Charging management; Wireless Local Area 

Network (WLAN) charging". 

[13]-[19] Void 
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[20] 3GPP TS 32.260: "Telecommunication management; Charging management; IP Multimedia 

Subsystem (IMS) charging". 

[21]-[29] Void. 

[30] 3GPP TS 32.270: "Telecommunication management; Charging management; Multimedia 

Messaging Service (MMS) charging". 

[31] 3GPP TS 32.271: "Telecommunication management; Charging management; Location Services 

(LCS) charging". 

[32] 3GPP TS 32.272: "Telecommunication management; Charging management; Push-to-talk over 

Cellular (PoC) charging". 

[33] 3GPP TS 32.273: "Telecommunication management; Charging management; Multimedia 

Broadcast and Multicast Service (MBMS) charging". 

[34] 3GPP TS 32.274: "Telecommunication management; Charging management; Short Message 

Service (SMS) charging". 

[35] 3GPP TS 32.275: "Telecommunication management; Charging management; MultiMedia 

Telephony (MMTel) charging". 

[36] -[49] Void. 

[50] 3GPP TS 32.299: "Telecommunication management; Charging management; Diameter charging 

application". 

[51] Void. 

[52] 3GPP TS 32.297: "Telecommunication management; Charging management; Charging Data 

Records (CDR) file format and transfer" . 

[53]-[99] Void. 

[100] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[101] 3GPP TS 22.115 "Service aspects; Charging and bilUng". 

[101]-[109] Void. 

[200] Void. 

[201] 3GPP TS 22.024: "Description of Charge Advice Information (CAI)". 

[202] 3GPP TS 23.078: "Customized Applications for Mobile network Enhanced Logic (CAMEL) 

Phase 4 -Stage 2". 

[203] 3GPP TS 23.003: "Numbering, addressing and identification". 

[204] 3GPP TS 29.002: "Mobile Application Part (MAP) specification". 

[205]-[299] Void. 

[300]-[399] Void. 

[400] Void. 

[401] IETF RFC 3588: "Diameter Base Protocol". 

[402] IETF RFC 4006: "Diameter Credit-Control Application". 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TR 21.905 [100], 3GPP TS 32.240 
[ 1 ] and the following apply: 

account: structure residing in the OCS for holding dynamic subscriber data with monetary equivalence. Accounts may 
have a currency or a unit type. As opposed to bank accounts, transaction history is not necessarily kept in the OCS 
account data structure. 

account balance: the current value of an account of service usage. 

chargeable event: activity utilizing telecommunications network resources and related services for: 

• user to user communication (e.g. a single call, a data communication session or a short message); or 

• user to network communication (e.g. service profile administration); or 

• inter-network communication (e.g. transferring calls, signalling, or short messages); or 

• mobility (e.g. roaming or inter-system handover); and 

• that the network operator may want to charge for. 

As a minimum, a chargeable event characterises the resource / service usage and indicates the identity of the involved 
end user(s). 

charging: a function within the telecommunications network and the associated OCS/BD components whereby 
information related to a chargeable event is collected, formatted, transferred and evaluated in order to make it possible 
to determine usage for which the charged party may be billed (offline charging) or the subscribers account balance may 
be debited (online charging). 

counter: temporary aggregation of units of service usage or monetary units, which may be in relation to subscriber 
contractual terms (e.g. number of used SMS per day or number of free minutes per month). 
These form the basis for any type of loyalty program like discounts or bonus. 

domain: part of a communication network that provides services using a certain technology 

offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered 

online charging: charging mechanism where charging information can affect, in real-time, the service rendered and 
therefore a direct interaction of the charging mechanism with session/service control is required 

tariff: set of parameters defining the network utilization charges for the use of a particular bearer / session / service 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

Bo Offline Charging Reference Point towards the operator's post-processing system 

Ga Reference point for CDR transfer between a CDF and the CGF 

Re Online Charging Reference Point towards the Account Balance Management Function 

Re Online Charging Reference Point towards the Rating Function 

Ro Online Charging Reference Point towards the online charging functions (EBCF, SBCF) 

Rr Online Charging Reference Point towards an external account recharging server 
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3.3 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

APN Access Point Name 

AoC Advice of Charge 

CAMEL Customized Applications for Mobile network Enhanced Logic 

CAP CAMEL AppUcation Part 

CCA Credit Control Answer 

CCR Credit Control Request 

CDF Charging Data Function 

CDR Charging Data Record 

CGF Charging Gateway Function 

CS Circuit Switched 

CSCF Call Session Control Function 

EBCF Event Based Charging Function 

ECUR Event Charging with Unit Reservation 

EPS Evolved Packet System 

E-UTRAN Evolved Universal Terrestrial Radio Access Network 

FBC Flow Based Charging 

GMLC Gateway Mobile Location Center 

GPRS General Packet Radio Service 

HTTP HyperText Transfer Protocol 

lEC Immediate Event Charging 

IMS IP Multimedia core network Subsystem 

IMSI International Mobile Subscriber Identity 

IP Internet Protocol 

ISC IMS Service Control 

ISDN Integrated Services Digital Network 

LCS Location Services 

MAP Mobile Application Part 

MBMS Multimedia Broadcast and Multicast Service 

MMS Multimedia Messaging Service 

MSC Mobile Services Switching Centre 

MSISDN Mobile Station ISDN number 

MVNO Mobile Virtual Network Operator 

OCF Online Charging Function 

OCS Online Charging System 

PCC Policy and Charging Control 

PCEF Policy and Charging Enforcement Function 

PoC Push-to-talk over Cellular 

PRQ PriceRequest 

PRS PriceResponse 

PS Packet-Switched 

P-GW PDN Gateway 

QoS Quality of Service 

RF Rating Function 

SBCF Session Based Charging Function 

SGSN Serving GPRS Support Node 

SIP Session Initiation Protocol 

SMS Short Message Service 

SUQ ServiceUsageRequest 

SUS ServiceUsageResponse 

TRQ TarifflRequest 

TRS TariffResponse 

URL Uniform Resource Locator 

WLAN Wireless Local Area Network 
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4 Required functionality of the OCS 

The Online Charging System (OCS) shall support mechanisms for: 

• online bearer charging towards access / core network entities (e.g. SGSN, PCEF, WLAN). Online charging 
interfaces to be supported are Ro and CAP; 

• online charging of applications/services that are provided to subscribers via service nodes (outside the core 
network) e.g. MMS and LCS. The online charging interface to be supported is Ro; 

• IMS online charging. Online charging interface to be supported is Ro; 

• account balance management towards external account management servers e.g. recharge server, hot billing 
server; 

• generation of Charging Data Records (CDRs) and their transfer to the operator's post-processing system. 
The Online Charging System (OCS) may optionally support mechanisms for: 

• correlation of bearer, service and IMS charging. 

To support these requirements, the functions listed below are necessary in the OCS: 

1. rating (before and/or after service consumption): 

• unit determination: calculation and reservation of a number of session-related non-monetary units (service 
units, data volume, time and events); 

• price determination: calculation of monetary units (price) for a given number of non-monetary units; 

• tariff determination: determination of tariff information based on the subscribers contractual terms and 
service being requested (e.g. e-parameters for AoC); 

• get/set counters applicable for rating (alternatively these counters can be here or in the subscriber account 
balance management; for further details refer to subclause 5.2.2). 

2. subscriber account balance management: 

• check account balance; 

• account balance update (credit/debit); 

• account balance reservation; 

• get/set counters; 

• get/set expiry date of the (prepaid) account (optional). 

3. charging transaction control: 

• perform charging control on request basis for bearer and events/services; 

• immediate charging and charging with reservation; 

• generation of charging information/CDR per charging transaction. 

To support the correlation requirements, the functions listed below are possible in the OCS: 

4. correlation function: 

• context handling of bearer, service and IMS charging events related to a given subscriber; 

• generation of a combined multiple event and session requests to the rating function. 
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5 Architectural concept 

5.1 Architecture reference model for online charging 

Figure 5.1 shows the OCS in the framework of the overall charging architecture as defined in 3GPP TS 32.240 [1]. The 
present document covers only the OCS internal architecture (i.e. the blue box in figure 5.1). 
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NOTE 1 : The Re, Re and Ga reference points connect both Online Charging Functions (i.e. the Session Based 

Charging Function and the Event Based Charging Function) with the Account Balance Management 

Function, the Rating Function and the Charging Gateway Function. 
NOTE 2: The support of ISC as charging interface towards IMS CSCF requires additional functionality to be 

provided by the OCS. The support of Ro as charging interface towards OCS requires additional 

functionality to be provided by the IMS CSCF. 
NOTE 3: Only networl< entities covered in this Release are depicted. Other network entities may be connected to 

the OCS, but these are out of scope for the current release. 

Figure 5.1 : Online charging system architecture 
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Towards the SGSN, the OCS or a separate function could provide a translation between CAP and Ro. This is beyond 
the scope of the present document. 

In case of Flow Based Charging (FBC), the PCEF is used for all FCC interactions between P-GW and OCS, for details 
refer to 3GPPTS 32.251 [11]. 

For architectural details on the Ro reference point between WLAN and OCS, refer to 3GPP TS 32.252 [12]. 

The architecture details on the Ro reference point used for IMS (IMS CSCF, IMS Application Server and IMS MRFC) 
specified in 3GPP TS 32.260 [20]. 

The service specific architecture details on the Ro reference point are specified for the MMS Relay/Server in 3GPP TS 
32.270 [30], for the GMLC in 3GPP TS 32.271 [31], for the PoC Server in 3GPP TS 32.272 [32] for the MEMS Server 
in 3GPP TS 32.273 [33], for the SMS in 3GPP TS 32.274 [34] and the MMTel in 3GPP TS 32.275 [35]. 

The Session Based Charging Function (SBCF) performs session based charging on the bearer level using the CAP 
interface towards MSC and SGSN, and the Ro reference point towards other network elements. The Session Based 
Charging Function (SBCF) also performs session based charging on the subsystem level (i.e. IMS session charging) 
using the Ro reference point towards the IMS CSCF. Whether the CSCF is directly connected to the OCS or via a 
gateway (IMS Gateway Function) is beyond the scope of the present document. 

The Event Based Charging Function (EBCF) performs event-based charging using the CAP interface towards MSC and 
SGSN (e.g. for charging of SMS), and the Ro reference point towards other network elements. 

The Rating Function and the Account Balance Management Function are described in clause 4. The Re reference point 
allows the interaction between the Online Charging Functions (SBCF, EBCF) and the Rating Function. 

The Re reference point allows the interaction between the Online Charging Functions (SBCF, EBCF) and the Account 
Balance Management Function to access the subscribers account balance. 

The Ga reference point allows the collection and transfer of charging information from the Charging Data Functions 
(CDF) to the Charging Gateway Function (CGF). In the context of online charging, the CDFs are always integrated into 
the Online Charging Functions (SBCF, EBCF). Whether the CGF is also integrated into the Online Charging Functions, 
or whether it is a separate function inside the OCS, or whether it is an external function outside the OCS is not defined 
in this 3GPP release. 

The Bo reference point allows the transfer of charging information from the Charging Gateway Function to the 
operator's post-processing system as the OCS variant of the Bx interface description in 3GPP TS 32.297 [52]. 

The Rr reference point allows the interaction between the Account Balance Management Function and an external 
recharging server. 

There may be other external systems connected to the OCS (e.g. hot billing server). These systems are not considered in 
the present document. 
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5.2 Functions within the OCS 

5.2.1 Online Charging Functions 

5.2.1 .1 Event Based Charging Function 

The Event Based Charging Function (EBCF) performs event based charging and credit control (e.g. content charging): 

• on the bearer level, based on bearer usage requests received from the network. It controls the bearer usage in the 
network, e.g. SMS; 

• on a subsystem level, based on session resource usage requests received from the network (e.g. the IMS MRFC). 
It controls the resource availability in network, e.g. it has the ability to grant or deny the resource usage; 

• on service level, based on application server requests received from the network (e.g. an IMS application server 
or MMS relay server). It controls the application service availability in the network, e.g. it has the ability to grant 
or deny the service usage in the network. 

It communicates with the Rating Function in order to determine the value of the requested service usage. It 
communicates with the Account Balance Management Function to query and update the subscribers' account and 
counters status (counters are not applicable if a class "B" Rating Function is used). 

When a correlation process is enabled a correlation context may be consulted or created. If multiple chargeable events 
exist in the correlation context a combined request will be issued for the Rating Function. 

5.2.1 .2 Session Based Charging Function 

The Session Based Charging Function (SBCF) performs session based charging and credit control: 

• on the bearer level, based on bearer usage requests received from the network. It controls the bearer usage in the 
network, e.g. in terms of time or volume granted; 

• on the subsystem level, based on session resource usage requests received from the network (e.g. the IMS 
CSCF). It controls sessions in the network, e.g. it has the ability to grant or deny a session setup request and to 
terminate an existing session; 

• on the service level, based on service usage requests received from the network. It controls service availability in 
the network, e.g. it has the ability to grant or deny a usage of a service. 

It communicates with the Rating Function in order to determine the value of the requested bearer resources or the 
requested session. It communicates with the Account Balance Management Function to query and update the 
subscribers' account and counters status (counters are not applicable if a class "B" Rating Function is used). 

When a correlation process is enabled a correlation context may be consulted or created. If multiple chargeable events 
exist in the correlation context a combined request will be issued for the Rating Function. 



£75/ 



3GPP TS 32.296 version 8.2.1 Release 8 16 ETSI TS 132 296 V8.2.1 (2009-01) 



5.2.2 Rating Function 



The Rating Function performs both monetary and non-monetary unit determination (rating). It provides the following 
functionalities: 

• Rating for network- and external services and applications (session, service, event) before and after service 
delivery; 

• Cross-product and cross-channel discounts, benefits and allowances. 

The Rating Function must be able to handle a wide variety of rateable instances, such as: 

• Rating of volume (in terms of granted units or money, e.g. based on charging initiated by an access network 
entity); 

• Rating of time (in terms of granted units or money, e.g. based on charging initiated by a SIP appUcation); 

• Rating of events (e.g. based on charging of web content or MMS). 

The Rating Function includes the determination of the tariff or the price of a chargeable event or of multiple chargeable 
events (correlation scenario); examples include the price of a call minute, data volume, multimedia session, Web 
content, etc. 

Upon receipt of a rate request (price or tariff request) from the Charging Function, the Rating Function: 

• Evaluates the request. Rate requests include various rating parameters such as service identifier, subscriber 
reference, network identification, user location, service usage time, transferred data volume, etc. Note that the 
rate request may contain multiple service identifiers that reflect the list of active services contained in the context 
handled by the Charging Function. 

• Determines the appUcable price or tariff model and returns it to the Charging Function. Note that in case of 
multiple service requests received, the Rating Function may apply a special price or tariff which can be different 
to the price or tariff applied to the related services handled separately. For example when sending an MMS, the 
rating of volume associated with the bearer usage can be free of charge while the rating of the event and/or 
volume associated with the service level MMS submission is greater than zero. This correlation procedure 
depends on the operator configurable rating rules. 

To support the online rating process, the Rating Function needs counters. The counters may be maintained by the 
Rating Function or by the Account Balance Management function. A Rating Function that does not maintain counters 
will be marked as class "A" Rating Function. A Rating Function that maintains counters will be marked as class "B" 
Rating Function. 

Editor's Note: The handling of combined session and event requests is for further study. 
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6 Functionalities and IVIessage Flows 

6.1 Reference Point Required Functionality 

6.1 .1 Re Reference Point (EBCF, SBCF - Rating Function) 

6.1 .1 .1 Functionality for class "A" Rating Function 

The following applies with respect to the Rating Interface: 

• The Rating Function will potentially cover all rating scenarios for all charging levels (bearer, session and 
service) and all payment channels (prepaid and postpaid). 

• The Rating Function will cover the methods PriceRequest and TariffRequest. 

• The Rating Function will operate in a stateless way on a per request basis. No context or state is stored 
internally. 

• The Rating Function will not modify accounts or bonus counters directly. Instead it passes the corresponding 
information (instruction how to modify counters) as part of the response. Details are explained in the next 

subsection. 

• The Rating Interface is an interface in a trusted environment. Session handling, transaction control or 
authentication / authorization are not required. 

• No records are written by the Rating Function. Thus billing relevant information is part of the response. 
Resulting from these requirements following functionality of Re reference point is proposed: 

Basic methods: 

• Price Request (to calculate a price for given service usage); 

• Tariff Request (to request a tariff that is applicable, e.g. e-parameters). 
Additional supported functionalities: 

• Discounts by use of consumer specific counters; 

• Loyalty programs; 

• Taxes; 

• Detailed information for use during invoice generation. 

Depending on the service or product offered and on the customer's contract, the Rating Function supports the following 
methods: 

• PriceRequest: Determination of a price for the execution of a service or the delivery of a good. From the rating 
perspective this is the same method if run before delivery (e.g. for balance check or AoC), after delivery (post- 
rating for charging) or even later in a rerating process. The same method applies for one-time or recurrent 
charges. The PriceRequest is used by the EBCF. 

• TariffRequest: Determination of a tariff for a given service. This method is used, e.g., for voice calls, where e- 
parameters are returned by the Rating Function. Based on the tariff (e-parameters) the charging function 
calculates either the amount of units for a given price or the price for a given number of units. The method can 
also be used for various other services. The TariffRequest is used by the SBCF. 

Input for Rating: 

• Rating Request Type: Price Request, Tariff Request. 
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• Service-specific data: Service-ID, Time/Date of Service usage, QoS, etc. 

• Subscriber-specific static data: Subscriber-ID, Partner-ID (e.g. MVNO, merchant), additional tariff information 
(e.g. "Friends & Family" list), other static data. 

• Subscriber specific dynamic data: Account Balances incl. units/currency (money, loyalty). Subscriber Counters 
(e.g. Service-Type (SMS/MMS/Volume/Time) used per time-unit (day/week/month/year), other dynamic data). 

Output of Rating: 

• Rating Request Type Response: Price or Service units or Tariff incl. tariff switch information 

(e-parameters. Tariff Switch Time (absolute time/duration), etc.); 

• Charge and Recharge Information: Value for accounts and Subscriber Counters (e.g. charge money, recharge 
loyalty accounts); 

• Tax information; 

• Detailed information to be used for invoice generation. 

6.1.1.1.1 Class "A" Counter Handling 

As defined in subsection 5.2.2, if a class "A" Rating Function is used, counters reside in the Account Balance 
Management Function. The Charging Functions fetch the counters from the Account Balance Management Function 
over the Re Reference Point at the beginning of an online charging session, together with the account balance. The 
counter values are passed on to the Rating Function in the PriceRequest or TariffRequest method over the Re Reference 
Point. On the Re Reference Point, counters have to be supported in a very generic way in order to support the use of 
counters in the largest possible variety of call scenarios. The structure of counter elements on the Re interface is defined 
in section 7 of this document. 

In the Rating Request, the Charging Function will inform the Rating Function about the current value and the expiry 
date of all applicable counters. 

In the Rating Response, the Rating Function may instruct the Charging Function to modify counters. The following 
kinds of counter manipulation are supported: 



• 



increase or decrease one or more specified counters with a specified value, once for this online charging session; 

• increase or decrease one or more specified counters with a specified value per consumed service unit; 

• increase or decrease one or more specified counters with a specified value per charged unit (i.e. a charged unit as 
defined by the e-parameters E2, E6, or E7); the specified value and the e-parameters may change due to a tariff 
switch; 

• set one or more specified counters explicitly to a specified value; this instruction can be used to reset counters; 
if the specified counter does not exist, the Charging Function shall create this counter in the Account Balance 
Management Function; hence, using this instruction, the Rating Function can trigger the creation of new 
counters; 

• set a counter threshold for one or more specified counters; when a threshold is reached, the tariff information 
from the Rating Response message expires, and the Charging Function shall send a new Rating Request message 
towards the Rating Function; 

• set the expiry date of one or more specified counters. 

Additionally, the Rating Function may give the following information to the Charging Function: 

• a list of counters, which are applicable to the present online charging session; the Charging Function shall 
include only these counters in subsequent rating requests within this session; the list of applicable counters can 
be modified by the Rating Function in each Rating Response; the purpose of this information is to reduce load on 
the Re-interface. 

Note that from a principal point of view, in class "A" the account balance can be considered as a special kind of 
counter: It resides in the Account Balance Management Function, it has a current value and an expiry date, and it will 
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be modified during an online charging session by the Charging Function according to resource usage and according to 
information received from the Rating Function. 

6.1 .1 .2 Functionality for class "B" Rating Function 

If class "B" Rating Function is chosen, i.e. counters are maintained in the Rating Function, then the Re Reference Point 
is modified with respect to the previous clause in the following way: 

• the Rating Function has to become statefull; 

• the Rating Function has to modify counters directly; 

• the Rating Function has to handle sessions / has to support transaction control; 

• the PriceRequest and TariffRequest have to support reservations; 



• 



TariffRequest: Determination of a tariff and price for a given session oriented service. This method is used, e.g., 
for voice calls, where e-parameters are returned by the Rating Function. At the beginning or during the session, 
the Rating Function receives requested service units and returns the tariff information (e-parameters). The 
charging function can grant the requested units or recalculate the granted units based on the returned tariff and 
the account balance. At the end of the session, the Rating Function returns the conclusive price of the consumed 
service. The method can also be used for various other services. The TariffRequest is used by the SBCF. 

Scenarios involving granted units may be covered via a TariffRequest or by the Class "B" Rating Function directly. The 
handling of the first case is part of the charging function. For the latter case the Re interface offers a special request 
type: 

• ServiceUsageRequest: This type of request, also called backward rating, determines the amount of units of a 
given service given the price. The ServiceUsageRequest is useful (but not limited) in the case where the 
subscriber's price plan is formed in usage per monetary units amount (e.g. 45 seconds per 100 Yen). Since the 
basic requirements are covered by the former requests, this request is optional. 

6.1 .2 Re Reference Point (EBCF, SBCF - Account Balance Management 
Function) 

To be defined in a later release. 
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6.2 Re Message Flows 



This subclause describes message flows for the Re Reference Point by explaining example online charging sessions (i.e. 
credit control sessions on the Ro interface or CAP dialogues). 

On the interface towards the serving network nodes (i.e. Ro, CAP) the generic message names "online charging request" 
and "online charging response" are used. These generic names should be mapped to real messages depending on the 
type of interface as indicated in the following table. 



generic name 


Ro Interface 


CAP Interface 


online charging 
request 


Credit Control Request 
(CCR) 


first message, initiating tlie ctiarging dialogue: 

• Initial DP, 

• Initial DP GPRS, 

• Initial DP SMS 
subsequent messages: 

• Apply Charging Report, Event Report BCSIVI, 

• Apply Charging Report GPRS, Event Report GPRS, 

• Event Report SIVIS 


online charging 
response 


Credit Control Answer 
(CCA) 


• Apply Charging, Request Report BCSM Event (+ Connect / 
Continue), 

• Apply Charging GPRS, Request Report GPRS Event (+ Connect 
GPRS/ 

Continue GPRS), 

• Request Report SMS Event, Connect SMS, Continue SMS 



For details on the CAP messages and message flows, refer to 3GPP TS 23.078 [202]. 

It should be noted that several service requests can be included in one message using Services-Rating AVP. The basic 
functionality of the single or multiple requests are the same so only single request scenario is described in message 
flows. 

In addition to the differences between a class "A" and a class "B" Rating Function as described in the previous 
subclause, the Re message flows of both classes differ from a principal point of view as follows: 

• In class "A", a TariffRequest is sent by the ChargingFunction only when an online charging request is received 
from the network, and no valid tariff is known (i.e. at the beginning of an online charging session or after tariff 
expiry). Therefore, distinction between different scenarios in the following description is necessary. 

• In class "B", a TariffRequest is sent by the ChargingFunction after every online charging request received from 
the network. Therefore, no distinction between different TariffRequest scenarios is necessary. 
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6.2.1 Class "A" Rating Function Message Flows 
6.2.1 .1 PriceRequest method 

The PriceRequest method is used only for event based charging, i.e. only the EBCF uses this method. 

According to 3GPP TS 32.299 [50], two different scenarios need to be distinguished, the Immediate Event Charging 
(lEC) and the Event Charging with Unit Reservation (ECUR). 

Both scenarios in this section describe the case where the EBCF invokes the PriceRequest method for charging or 
Advice of Charge. 



6.2.1.1.1 



PriceRequest scenario with Immediate Charging 



The following figure describes the case where the EBCF invokes the PriceRequest method in an Immediate Event 
Charging (lEC) scenario. 
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Figure : Price Request IVIethod with immediate charging 

Step 1: The EBCF receives an online charging request for a certain event/service. 

Step 2: The EBCF requests account and counter information for the subscriber from the Account Balance 

Management Function. 

Step 2' (Optional):In case there is no existing subscriber's context, the EBCF creates a new subscriber's context 
information. Otherwise, the EBCF updates the existing subscriber's context and gets the list of 
active services for the given subscriber (see note below). This Step only applies when correlation 
is enabled. 

Step 3: Upon receipt of this data, the EBCF sends a price request to the Rating Function in order to 

determine the price of the desired service. Note that this scenario assumes that the EBCF has not 
received any service cost information in the online charging request. Note that the Price Request 
may contain several service requests depending on the number of ongoing services. 
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Step 4: The Rating Function calculates the price and counter updates for the given service according to the 

service and subscriber specific information included in the request. 
Step 5: The calculated price and counter updates are returned to the EBCF. 

Step 6: The EBCF continues event charging and performs account and counter control (i.e. it checks and 

adjusts the account and counter values). 
Step 7: The EBCF sends the appropriate online charging response. 

If the Price Request Method with immediate charging is used, the service delivery may occur before or after the online 
charging dialogue. 

In addition to the price, the PriceResponse may also include "Basic Price". This may be used e.g. to realize a basic fee, 
that is applicable once per day/week/month, if a certain service is used. Note that the Basic Price may be service 
specific. The EBCF has to include the timestamp of the last charging of the Basic Price in the PriceRequest, if the Basic 
Price is applicable. This handling applies also for the PriceRequest scenario with Unit Reservation as described in the 
following subsection. 

NOTE: If a context already exists when the EBCF interrogates the context, then the EBCF may optionally get the 
price for the desired service. 
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6.2.1.1.2 



PriceRequest scenario with Unit Reservation 



The following figure describes the case where the EBCF invokes the PriceRequest method in an Event Charging with 
Unit Reservation (ECUR) scenario. 
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Figure : Price Request Method with unit reservation 

Step 1: The EBCF receives an online charging request for a certain event/service. 

Step 2: The EBCF requests account and counter information for the subscriber from the Account Balance 

Management Function. 
Step 2' (Optional):ln case there is no existing subscriber's context, the EBCF creates a new subscriber's context 

information. Otherwise, the EBCF updates the existing subscriber's context and gets the list of 

active services for the given subscriber (see note below). This Step only applies when correlation 

is enabled. 
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Step 3: Upon receipt of this data, the EBCF sends a price request to the Rating Function in order to 

determine the price of the desired service. Note that this scenario assumes that the EBCF has not 

received any service cost information in the online charging request. 
Step 4: The Rating Function calculates the price and counter updates for the given service according to the 

service and subscriber specific information included in the request. 
Step 5: The calculated price and counter updates are returned to the EBCF. 

Step 6: The EBCF continues event charging and performs account and counter control (i.e. it makes 

reservations for the requested service). 
Step 7: The EBCF sends the appropriate online charging response (i.e. it grants or denies service delivery). 

Step 8: After service delivery, the serving network node sends an indication of successful (or 

unsuccessful) service delivery to the EBCF. 
Step 9: The EBCF performs account and counter control (i.e. it adjusts the account and counter values 

accordingly). 
Step 10: Finally, the EBCF sends an acknowledgment message to the serving network node in order to 

terminate the online charging dialogue. 

If the second online charging request (step 8) contains updated information about the consumed service, a second Price 
Retrieval Operation may occur between step 8 and step 9, i.e. the EBCF may send a second PriceRequest containing the 
updated information to the Rating Function. The Rating Function will send an appropriate PriceResponse, and the 
information contained in this second PriceResponse may be used by the EBCF for account and counter control (step 9). 

If the second online charging request (step 9) contains information about the release of the ongoing service, the EBCF 
updates the existing subscriber's context to remove the entry related to this service and to get the list of remaining active 
services. A second Price Retrieval Operation may occur between step 9 and step 10', i.e. the EBCF may send a second 
PriceRequest containing the updated information to the Rating Function. The Rating Function will send an appropriate 
PriceResponse containing the updated price for the remaining ongoing services and the information contained in this 
second PriceResponse may be used by the EBCF for account and counter control (step 10). 



£75/ 



3GPP TS 32.296 version 8.2.1 Release 8 25 ETSI TS 132 296 V8.2.1 (2009-01) 

6.2.1 .2 Tariff Request method 

The TariffRequest method is used for bearer charging and IMS session charging, i.e. only the SBCF uses this method. 

All scenarios in this section describe the case where the SBCF invokes the tariffRequest method for charging or Advice 
of Charge. All scenarios are valid independent of the type of applicable "units" (i.e. for both, time or volume). 

In the context of bearer charging or session charging, only the Event Charging with Unit Reservation (ECUR) 
(3GPP 32.299 [50]) is relevant. Therefore, only ECUR is considered in this section. 
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6.2.1 .2.1 Basic TariffRequest scenario 

The following figure shows a basic message flow for the tariff request method. 
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Figure : Basic Tariff request method 
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Step 1: 
Step 2: 




Step 2' 


(Optiona 


Step 3: 
Step 4: 
Step 5: 
Step 6: 
Step 7: 





Step 8: 

Step 9: 

Step 10 
Step 1 1 
Step 12 

Step 13 
Step 14 
Step 15 
Step 16 



The SBCF receives an online charging request referring to an MS's bearer/session resource usage. 
The SBCF requests account and counter information for the subscriber from the Account Balance 
Management Function. 
l):In case there is no existing subscriber's context, the EBCF creates a new subscriber's context 
information. Otherwise, the EBCF updates the existing subscriber's context and gets the list of 
active services for the given subscriber. This Step only applies when correlation is enabled. 
Upon receipt of this data, the SBCF requests tariff information applicable for this bearer/session. 
The Rating Function retrieves the appropriate tariff to be applied for the bearer/session. 
The Rating Function returns the tariff information to the SBCF. 

Based on the received tariff information, the SBCF determines the granted units and the price. 
The SBCF continues bearer/session charging and performs account and counters control (i.e. it 
makes reservations). 

Assuming successful account control, the SBCF returns the granted units to the requesting network 
element. Service usage can start immediately or later. 

When the granted units have been used, a new request is send from the serving network element to 
the SBCF. 

This time the SBCF can directly determine the granted units and the price. 
The SBCF performs account and counter control (i.e. it makes reservations). 
Again, assuming successful account control, a positive acknowledgment (including granted units) 
is returned to the network entity. 

The MS terminates bearer/session usage. The used units are sent to the SBCF. 
The SBCF performs final rating for the consumed bearer/session resources. 
The SBCF adjusts the account and counters accordingly. 

Finally, the SBCF sends an acknowledgment message to the serving network node in order to 
terminate the online charging dialogue. 



In this basic scenario only one request to the Rating Function is needed during the whole online charging session. 

The message flow in the previous figure is an example of an online charging session to illustrate the usage of the basic 
Tariff Request method on the Re interface. The sequence of steps 6-9 can be repeated multiple times (or they can be 
missing completely, if the session ends before the first quota of granted units is consumed). 

If the SBCF detects that the account balance is not sufficient for a minimum number of granted units (in step 6 in the 
example), there will be no reservation (step 7 will be skipped), and the SBCF will deny the online charging request (in 
step 8), i.e. the service usage request will be rejected by the mobile network. The same handling applies if the account 
reservation fails (in step 7, 1 1). Note that this can only occur, if the account is modified independently of the current 
online charging session, e.g. due to several parallel online charging sessions. This handling of insufficient account 
balances applies for all class "A" TariffRequest scenarios, i.e. also for the following subsections. 

This basic scenario assumes, that the tariff information is valid for the whole online charging session (i.e. the tariff is 
not affected by the amount of resources used, the time of day, etc.). 

In addition to the tariff information, the TariffResponse may also include "Basic Price", that is deducted directly from 
the subscriber's account balance. This may be used e.g. to realize a basic fee, that is applicable once per 
day/week/month, if a certain service is used. Note that the Basic Price may be service specific. The SBCF has to include 
the timestamp of the last charging of the Basic Price in the TariffRequest, if the Basic Price is applicable. This handling 
applies for all class "A" TariffRequest scenarios, i.e. also for the following subsections. 
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6.2.1 .2.2 TariffRequest Scenario with multiple Tariff Switches and Expiry Time 

The following figure shows a message flow for the tariff request method with multiple tariff switches, i.e. the tariff will 
change at specified times, multiple times during the online charging session. 

To allow for correct charging of this kind of scenarios, the rating function needs to make sure that all tariff information 
contained in a TariffResponse message expires between the next two tariff switches, i.e. between the tariff switch time 
that is defined within this TariffResponse message and the next subsequent tariff switch time. For this purpose, a 
parameter ExpiryTime is used. The ExpiryTime defines, how long the tariff information contained in the 
TariffResponse message is valid after the timestamp of the TariffRequest that triggered this response. For the handling 
of multiple tariff switches, it is recommended to set the ExpiryTime to the difference between the next two tariff switch 
times. 

It should be noted that the ExpiryTime may also be used when no tariff switch is foreseen, to ensure a subsequent tariff 
retrieval operation after a specified time period has passed. 
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Figure : Tariff request method with multiple tariff switches 

Step 1: The SBCF receives an online charging request referring to an MS's bearer usage/session resource 

usage. 
Step 2: The SBCF requests account and counter information for the subscriber from the Account Balance 

Management Function. 
Step 2' (Optional):In case there is no existing subscriber's context, the SBCF creates a new subscriber's context 

information. Otherwise, the SBCF updates the existing subscriber's context and gets the list of 

active services for the given subscriber. This Step only applies when correlation is enabled. 
Step 3: Upon receipt of this data, the SBCF requests tariff information applicable for this bearer/session. 

Step 4: The Rating Function retrieves the appropriate tariff to be applied for the bearer/session. 

Step 5: The Rating Function returns the tariff information to the SBCF, including indication of an 

upcoming tariff switch and the appropriate expiry time. 
Step 6: Based on the received tariff information, the SBCF determines the granted units and the price. 

Step 7: The SBCF continues bearer/session charging and performs account and counter control (i.e. it 

makes reservations). 
Step 8: It returns the granted units, an indication of the upcoming tariff switch, and the expiry time to the 

requesting network element. Service usage can start immediately or later. 

If supported by the online charging response message, the SBCF may return two quota of granted 

units, one valid before the tariff switch, the other valid after the tariff switch. 
Step 9: The (first) tariff switch occurs in the network. 

Step 10: When the granted units have been used, a new request is send from the serving network element to 

the SBCF. The units used before and after the tariff switch are sent to the SBCF as separate values 

in this request. 
Step 1 1 : Since the tariff information from the last TariffResponse (step 5) has not expired, the SBCF can 

directly determine the next granted units and the price. 
Step 12: The SBCF continues bearer/session charging and performs account and counter control (i.e. it 

makes reservations). 
Step 13: Again, assuming successful account control, a positive acknowledgment (including granted units 

and an indication of the expiry time) is returned to the requesting network element. 
Step 14: When the tariff expires (i.e. the expiry time is reached), a new request is send from the serving 

network element to the SBCF immediately. This request includes the number of units consumed so 

far. 
Step 15: The SBCF performs (final) rating for the bearer/session resources consumed so far. 

Step 16: The SBCF adjusts the account and counters accordingly. 

Step 17: The SBCF again requests tariff information applicable for the bearer/session. 

Step 18: The Rating Function retrieves the appropriate tariff to be applied for the bearer/session. 

Step 19: The Rating Function returns the tariff information to the SBCF, including indication of the next 

upcoming tariff switch and the appropriate expiry time. 
Step 20: Based on the received tariff information, the SBCF determines the granted units and the price. 

Step 21: The SBCF continues bearer/session charging and performs account and counter control (i.e. it 

makes reservations). 
Step 22: It returns the granted units, an indication of the next upcoming tariff switch, and the expiry time to 

the requesting network element. 
Step 23: The (second) tariff switch occurs in the network. 

Step 24: The MS terminates bearer/session usage. The units used before and after the (second) tariff switch 

are sent to the SBCF as separate values. 
Step 25: The SBCF performs final rating for the consumed bearer/session resources. 

Step 26: The SBCF adjusts the account and counters accordingly. 

Step 27: Finally, the SBCF sends an acknowledgment message to the serving network node in order to 

terminate the online charging dialogue. 



In this scenario one request to the Rating Function is needed for every tariff switch. No messages are sent at the time 
when a tariff switch occurs. The SBCF is informed about the units used before and after the tariff switch in the first 
online charging request, that is sent after the tariff switch has occurred (steps 10 and 24 in the example scenario). The 
handling when the tariff expires due to the parameter Expiry Time is similar to the closing of one online charging 
session and the immediate starting of a new online charging session. 

The message flow in the previous figure is an example of an online charging session to illustrate the usage of the Tariff 
Request method on the Re interface if handling of multiple tariff switches is required. Variations of this message flow 
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will occur, depending on the exact times when the tariff switches occur, on the number of tariff switches during the 
online charging session, etc. Of course, it is also possible that the granted units are used in the network or that the 
session ends without the occurrence of a tariff switch. 

If only one tariff switch is foreseen, the ExpiryTime parameter is not needed. In this case, the message flow will be 
identical to the basic scenario as described in subclause 6.2.1.2.1. A single tariff switch does not lead to any additional 
messages, nor does it require any additional handling in the SBCF. 
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6.2.1 .2.3 TariffRequest Scenario with limited validity 

The following figure shows a message flow for the tariff request method with limited validity, i.e. the tariff is only valid 
for a limited number of used service units (e.g. seconds, Kbytes) or until a counter threshold is reached. This scenario 
applies e.g. for regressive tariffs or for the usage of free / discounted service units. 
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Figure : Tariff request method with valid units 
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Step 1: 
Step 2: 
Step 2' (Optiona 



Step 4: 
Step 5: 



Step 6: 
Step 7: 

Step 8: 



Step 9: 

Step 10: 

Step 11: 

Step 12 
Step 13 
Step 14 
Step 15 

Step 16: 
Step 17: 

Step 18 
Step 19 
Step 20 
Step 21 
Step 22 



The SBCF receives an online charging request referring to an MS's bearer usage/session resource 
usage. 

The SBCF requests account and counter information for the subscriber from the Account Balance 
Management Function. 
l):In case there is no existing subscriber's context, the SBCF creates a new subscriber's context 
information. Otherwise, the SBCF updates the existing subscriber's context and gets the list of 
active services for the given subscriber. This Step only applies when correlation is enabled. Step 3: 
Upon receipt of this data, the SBCF requests tariff information applicable for this bearer/session. 
The Rating Function retrieves the appropriate tariff to be applied for the bearer/session. 
The Rating Function returns the tariff information to the SBCF, including indication of the number 
of units for which this tariff is valid. 

Based on the received tariff information, the SBCF determines the granted units and the price. 
The SBCF continues bearer/session charging and performs account and counter control (i.e. it 
makes reservations). 

It returns the granted units to the requesting network element. Service usage can start immediately 
or later. Note that the number of granted units is in general different from the number of "valid 
units" received from the Rating Function (i.e. the number of granted units can be smaller than the 
number of valid units). 

When the granted units have been used, a new request is send from the serving network element to 
the SBCF. 

The SBCF checks, whether all valid units have been used. If there are valid units left, the scenario 
continues with step 6 again. 

If all valid units have been used, the SBCF performs (final) rating for the bearer/session resources 
consumed so far. 

The SBCF adjusts the account and counters accordingly. 
The SBCF again requests tariff information applicable for the bearer/session. 
The Rating Function retrieves the appropriate tariff to be applied for the bearer/session. 
The Rating Function returns the tariff information to the SBCF, including indication of the number 
of units for which this tariff is valid. 

Based on the received tariff information, the SBCF determines the granted units and the price. 
The SBCF continues bearer/session charging and performs account and counter control (i.e. it 
makes reservations). 

It returns the granted units to the requesting network element. 
The MS terminates bearer/session usage. The used units are sent to the SBCF. 
The SBCF performs final rating for the consumed bearer/session resources. 
The SBCF adjusts the account and counters accordingly. 

Finally, the SBCF sends an acknowledgment message to the serving network node in order to 
terminate the online charging dialogue. 



In this scenario two requests to the Rating Function are needed during the online charging session. In general, one 
additional request is needed, whenever a tariff expires (i.e. whenever the number of valid units has been consumed or 
whenever a counter threshold is reached). The handling when the number of valid units has been consumed is similar to 
the closing of one online charging session and the immediate starting of a new online charging session. 

The message flow in the previous figure is an example of an online charging session to illustrate the usage of the Tariff 
Request method on the Re interface, if the tariff is valid only for a limited number of service units. The sequence of 
steps 6-10 can be repeated multiple times (as already indicated in step 6), and also the sequence of steps 6-15 can be 
repeated multiple times (i.e. including the complete consumption of valid units and a new request towards the Rating 
Function). 

An optional optimization of the message flow with respect to service availability is as follows: If the Charging Function 
is informed about the tariff that is valid after all valid units have been used, the SBCF can send an online charging 
response and grant the usage of a limited amount of units based on the new tariff immediately after all valid units have 
been used (i.e. after step 10); in parallel, the SBCF requests new tariff information from the Rating Function as 
described above (steps 1 1 - 15); when the granted units have been used, the mobile network will send an online 
charging request to the SBCF, and processing continues in step 16 as described above. 

A TariffRequest scenario with limited validity, where the tariff is only valid for a limited number of used service units, 
may also be combined with a tariff switch scenario (ref. subclause 6.2.1 .2.2). Operators should take care, that proper 
interworking is ensured. In general it is recommended, that the first condition that leads to tariff expiry (i.e. expiry time 
or consumption of all valid units) shall lead to an account and counters update and trigger a new TariffRequest towards 
the RatingFunction if interworking between these scenarios needs to be ensured. 
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6.2.1.2.4 



TariffRequest Scenario with unsolicited changes of session parameters 



The following figure shows a message flow for the tariff request method in a scenario, where the tariff depends on the 
Quality of Service (QoS). In this case, a new tariff applies whenever the QualityOfService in the network changes. The 
QoS change is an example of an unsolicited change of charging relevant session parameters in the network. 
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Figure : Tariff request method with charging based on QoS 
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Step 1: The SBCF receives an online charging request referring to an MS's bearer usage/session resource 

usage. 
Step 2: The SBCF requests account and counter information for the subscriber from the Account Balance 

Management Function. 
Step 2' (Optional):In case there is no existing subscriber's context, the SBCF creates a new subscriber's context 

information. Otherwise, the SBCF updates the existing subscriber's context and gets the list of 

active services for the given subscriber. This Step only applies when correlation is enabled. Step 3: 

Upon receipt of this data, the SBCF requests tariff information applicable for this bearer/session. 
Step 4: The Rating Function retrieves the appropriate tariff to be applied for the bearer/session. 

Step 5: The Rating Function returns the tariff information to the SBCF. 

Step 6: Based on the received tariff information, the SBCF determines the granted units and the price. 

Step 7: The SBCF continues bearer/session charging and performs account and counter control (i.e. it 

makes reservations). 
Step 8: It returns the granted units to the requesting network element. Service usage can start immediately 

or later. 
Step 9: When a QoS change occurs in the network, a new request is send from the serving network 

element to the SBCF immediately. This request includes the number of units consumed so far. 
Step 10: The SBCF performs (final) rating for the bearer/session resources consumed so far. 

Step 11: The SBCF adjusts the account and counters accordingly. 

Step 12: The SBCF again requests tariff information applicable for the bearer/session. Note that the new 

(changed) QoS is included in this request. 
Step 13: The Rating Function retrieves the appropriate tariff to be applied for the bearer/session. 

Step 14: The Rating Function returns the tariff information to the SBCF. 

Step 15: Based on the received tariff information, the SBCF determines the granted units and the price. 

Step 16: The SBCF continues bearer/session charging and performs account and counter control (i.e. it 

makes reservations). 
Step 17: It returns the granted units to the requesting network element. 

Step 18: The MS terminates bearer/session usage. The used units are sent to the SBCF. 

Step 19: The SBCF performs final rating for the consumed bearer/session resources. 

Step 20: The SBCF adjusts the account and counters accordingly. 

Step 21: Finally, the SBCF sends an acknowledgment message to the serving network node in order to 

terminate the online charging dialogue. 



In this scenario two requests to the Rating Function are needed during the online charging session. In general, one 
additional request is needed, whenever the QualityOfService changes in the network. A change in the QualityOfService 
is handled similar to the closing of one online charging session and the immediate starting of a new online charging 
session. 

The message flow in the previous figure is an example of an online charging session to illustrate the usage of the Tariff 
Request method on the Re interface, if the tariff expires due to an unsolicited change of charging relevant session 
parameters in the mobile network. Besides a QualityOfService change, other events in the network that could cause a 
tariff expiry include e.g. a location change, an SGSN change, etc. Also, e.g. the sequence of steps 6-9 can be repeated 
multiple times (if no QoS change occurs and the granted units have been used in step 9), and also the sequence of steps 
6-14 can be repeated multiple times (if multiple QoS changes occur). 
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6.2.2 Class "B" Rating Function Message Flows 
6.2.2.1 PriceRequest method 

The PriceRequest method is used only for event based charging, i.e. only the EBCF uses this method. 

According to 3GPP TS 32.299 [50], two different scenarios need to be distinguished, the Immediate Event Charging 
(lEC) and the Event Charging with Unit Reservation (ECUR). 



6.2.2.1.1 



PriceRequest scenario with Immediate Charging 



The following figure describes the case where the EBCF invokes the PriceRequest method in an Immediate Event 
Charging (lEC) scenario. 
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Figure : PriceRequest method with Immediate Charging 



Step 1: 
Step r 



Step 2: 



Step 3: 

Step 4: 
Step 5: 



The EBCF receives an online charging request for a certain event/service. 
(Optional):In case there is no existing subscriber's context, the EBCF creates a new subscriber's context 
information. Otherwise, the EBCF updates the existing subscriber's context and get the list of 
active services for the given subscriber. This Step only applies when correlation is enabled. 
The EBCF sends a price request with a reserve instruction to the Rating Function to determine the 
price of the desired service. Please note that this scenario assumes that the EBCF has not received 
any service cost information in the online charging request. 

The Rating Function calculates the price and reserves the counters related to the given service 
according to the service and subscriber specific information included in the request. 
The calculated price is returned to the EBCF. 

The EBCF continues event charging and performs account control (i.e. it checks and adjusts the 
account balance). 
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Step 6: The EBCF sends the appropriate onhne charging response (i.e. service granted or denied, based on 

the account control result). 
Step 7: Assuming a successful account control, the EBCF sends a price request with a debit instruction to 

the Rating Function. Otherwise, the EBCF sends a price request with a release instruction. 
Step 8: The Rating Function updates or releases counters as appropriate. 

Step 9: The Rating Function acknowledges the operation to the EBCF. 

Note that from the network perspective there is immediate charging as described in 3GPP TS 32.299 [50], i.e. there is 
no reservation on the account balance. Nevertheless, internal reservations in the OCS on the counters may be involved 
as shown here. 
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6.2.2.1.2 



PriceRequest scenario with Unit Reservation 



The following figure describes the case where the EBCF invokes the PriceRequest method to make reservation but 
debits after service delivery. Two PriceRequests are always issued (Reserve & Debit). 

The service parameters may be changed in the second request. 
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Figure : PriceRequest method with Unit Reservation 



Step 1: 
Step r 



Step 2: 



Step 3: 

Step 4: 
Step 5: 
Step 6: 



The EBCF receives an online charging request for a certain event/service. 
(Optional):In case there is no existing subscriber's context, the EBCF creates a new subscriber's context 
information. Otherwise, the EBCF updates the existing subscriber's context and get the list of 
active services for the given subscriber. This Step only applies when correlation is enabled. 
The EBCF sends a price request with a reserve instruction to the Rating Function in order to 
determine the price of the desired service. Please note that this scenario assumes that the EBCF 
has not received any service cost information in the online charging request. 
The Rating Function calculates the price and reserves the counters related to the given service 
according to the service and subscriber specific information included in the request and 
the calculated price is returned to the EBCF. 

The EBCF reserves the calculated price from the subscriber's account. 

Upon successful reservation it grants the service usage or rejects the service if there is insufficient 
balance or if the reservation fails. 
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Step 7: After service delivery, the serving network node sends an indication of successful (or 

unsuccessful) service delivery to the EBCF. (This step is omitted if the service was rejected in the 

previous step.) 
Step 8: Assuming a successful service delivery, the EBCF sends a price request with a debit instruction to 

the Rating Function. Please note that the request may contain updated information about the 

consumed service. If the service was rejected in step 6 or was not successfully delivered, the 

EBCF sends a price request with a release instruction instead. 
Step 9: The Rating Function re-calculates the price if needed and updates or releases the counters as 

necessary. 
Step 10: The final calculated price is returned to the EBCF if the service was delivered successfully. 

Otherwise a release acknowledgment is sent. 
Step 11: The EBCF performs account control, if applicable. 

Step 12: Finally, the EBCF sends an acknowledgment message to the serving network node in order to 

terminate the online charging dialogue, if the service was delivered successfully. 
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6.2.2.2 TariffRequest method 

The TariffRequest method is used for bearer charging and IMS session charging, i.e. only the SBCF uses this method. 

All scenarios in this section describe the case where the SBCF invokes the tariffRequest method for charging or Advice 
of Charge. All scenarios are valid independent of the type of applicable "units" (i.e. for both, time or volume). 

In the context of bearer charging or session charging, only the Session Charging with Unit Reservation (SCUR) 
(3GPP 32.299 [50]) is relevant. Therefore, only SCUR is considered in this section. 

6.2.2.2.1 TariffRequest scenario with successful service delivery 

The following figure describes the message flow for the tariff request method. The scenario describes the case where 
the SBCF invokes the tariffRequest method for charging several times during the same session, with successful 
reservation and service delivery. 
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Figure : Tariff request scenario with successful service delivery 
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Step 1: 

Step r (Optiona 



Step 2: 



Step 3: 

Step 4: 
Step 5: 

Step 6: 



Step 7: 



Step 8: 

Step 9: 

Step 9-14: 
Step 15: 

Step 16: 
Step 17: 



Step 18 
Step 19 
Step 20 



The SBCF receives an online charging request referring to an MS's bearer/session usage. 
l):In case there is no existing subscriber's context, the SBCF creates a new subscriber's context 
information. Otherwise, the SBCF updates the existing subscriber's context and get the list of 
active services for the given subscriber. This Step only applies when correlation is enabled. 
The SBCF requests tariff information applicable for this bearer/session. The initial amount of 
requested units is predetermined according to the operator policy. Note that the requested units are 
required for counters reservation in the Rating Function. 

The Rating Function retrieves the appropriate tariff to be applied for the bearer/session and 
reserves counter values if needed. 

The Rating Function returns the tariff information to the SBCF. 

Based on the received tariff, the SBCF calculates the price. The SBCF performs account balance 
reservation. 

If the reservation fails due to insufficient account balance, the SBCF recalculates the granted units 
and price based on the received tariff information and the available account balance. Note that the 
granted units are limited by the amount of requested units and the amount of valid units. The 
SBCF performs an adjusted account balance reservation. 

Assuming a successful account balance reservation, the SBCF returns the granted units to the 
requesting network element. Otherwise, the service is being denied (see subclause 6.2.2.2.2 for 
details). 

When the granted units have been used or the tariff has expired, a new request is send from the 
network element to the SBCF. 

The SBCF requests another quota of requested units for the service. The amount of requested units 
can be optimized, based on the tariff information and account balance. 
Repeat steps 2-7. 

The session ends and a final charging request is issued with updated session details (e.g. exact 
session length). 

The SBCF sends a final rating request with a debit instruction. 

The Rating Function performs final rating for the consumed resources and adjusts the counters 
accordingly. 

The Rating Function returns the final price to the SBCF. 
Based on the received price, the SBCF performs final account control. 

Finally, the SBCF sends an acknowledgment message to the serving network node in order to 
terminate the online charging dialogue. 



In this scenario a tariff request message is send whenever an online charging request is received from the mobile 
network. The first tariff request message at the beginning of the session is marked "with reservation". The last tariff 
request at the end of the session is marked "with debit". Any number (0 or more) of tariff requests (marked "with 
reservation") can appear during the session. During the session steps 9-14 can be repeated multiple times. Between any 
repetitions of those sequences, the charging session parameters that are relevant for rating may change. The change can 
be solicited (e.g. tariff switch) or unsolicited (e.g. QoS change). The network element issues another charging request in 
those cases i.e. on expiry time if tariff switch occurred, when granted units are consumed or QoS is changed. 

To allow for correct charging of this kind of scenarios, the rating function needs to make sure that all tariff information 
contained in a TariffResponse message expires between the next two tariff switches, i.e. between the tariff switch time 
that is defined within this TariffResponse message and the next subsequent tariff switch time. For this purpose, a 
parameter Expiry Time is used. The ExpiryTime defines, how long the tariff information contained in the 
TariffResponse message is valid after the timestamp of the TariffRequest that triggered this response. For the handling 
of multiple tariff switches, it is recommended to set the ExpiryTime to the difference between the next two tariff switch 
times. 

It should be noted that the ExpiryTime may also be used when no tariff switch is foreseen, to ensure a subsequent tariff 
retrieval operation after a specified time period has passed. 

The tariff request message contains session, subscriber and service information, the number of the requested units 
(quota) from the service and information about the previously consumed service quota, as applicable. 

In the first tariff request message, the number of the requested units is predetermined in the SBCF (e.g. according to the 
service; 15 Minutes for a data service as an example). The rating function retrieves the appropriate tariff, makes 
counters reservations and returns the tariff. 

In subsequent tariff request messages, the charging function can take into account the account balance and the applied 
tariff and try to optimize the number of the requested units in order to minimize the number of tariff retrievals. The 
charging function sends information on both, the passed quota and the new quota. Specifically, when a tariff switch 
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occurred, the charging function shall pass the consumed units before and after the tariff switch in the following tariff 
request message. The rating function, adjusts the reserved counters if needed as a result from the updated information. 
The rating function makes new counters reservations for the next quota and returns the tariff for the next quota. 

In the response to the tariff request message with reservation indication the rating function returns the applicable tariff. 
The charging function is responsible to calculate the price and to keep the account balance reservation accordingly. 

If the calculated price is higher than the account balance, the charging function shall re-calculate the price and the 
number of the granted service units based on the received tariff information and the account balance. The rating 
function will adjust the counter reservation based on the actual number of service units consumed in a subsequent Tariff 
Request message. 

In response to a TariffRequest message with debit indication, the TariffResponse message contains the final service 
price. 
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6.2.2.2.2 



TariffRequest scenario with service denial or unsuccessful delivery 



The following figure describes the message flow for the tariff request method. The scenario describes the case where 
the SBCF invokes the tariffRequest method and the service delivery is denied (e.g. due to insufficient account balance) 
or where the service is not delivered (e.g. party didn't answer). 



Mobile 
Network 



Ro, CAP- 



OCF 
(SBCF) 



Re- 



Rating Function 



Attempt to 
start the 
service 



Service 
was not 
delivered 



-1 . online charging request- 



1 '. create or update 

the subscriber's 

context data 



Tariff Retrieval (with reservation) 

2. TariffRequest (with reservation) 

(Requested Units) 



3. tariff retrieval - 

counters 

reservation 



4. TariffResponse 
(Tariff, TariffSwItchTlme, ExplryTime, ValidUnlts) 



5. Price 

claculatlon and 

account balance 

reserveatlon. 



6. Insufficient 

balance handling 

(conditional). 



7. online charging response 

-(granted units, TarlffSwItchTime,- 

ExpiryTime) 



8. online charging request _ 
(Service was not delivered) 



Tariff Retrieval (with release) 

-9. TariffRequest (with Release)— 



-1 1 . TariffResponse- 



10. Release 

counter 
reservations 



1 2. peform 
account control 



-13. online charging response- 



Figure : Tariff request scenario withi service denial or unsuccessful delivery 

Step 1-6: Repeat the same scenario in figure in subclause 6.2.2.2.1. 

Step 7: Assuming a successful account balance reservation, the SBCF returns the granted units to the 

requesting network element. Otherwise, the service is being denied. 
Step 8: The service is not delivered (e.g. the called party doesn't answer) and the network element informs 

the SBCF about the unsuccessful delivery. (If the service was denied on step 7, this step is 

omitted.) 
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Step 9: 
Step 10 
Step 1 1 
Step 12 

Step 13: 



The SBCF sends a Tariff Request with a release instruction. 

The Rating Function releases the counters accordingly. 

The Rating Function acknowledges the operation to the SBCF. 

The SBCF performs final account control (i.e. releases account balance reservations). If the 

reservation failed already in step 6, this step is omitted. 

Finally, the SBCF sends an acknowledgment message to the serving network node in order to 

terminate the online charging dialogue. 



In this scenario the service was not delivered in one of the following cases: 

• Service denied -e.g. in the case of insufficient account balance. 

• Service delivery unsuccessful -e.g. network failure or destination party doesn't answer. 

Reservations made to the account balance and to counters are fully released. The charging function is using a tariff 
request message with a release request subtype to explicitly denote that the service was not delivered. 
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6.2.2.3 ServiceUsageRequest with reservation method 

All message flows described in this section are applicable for the SBCF. 

In the context of bearer charging or session charging, only the Session Charging with Unit Reservation (SCUR) [50] is 
relevant. Therefore, only SCUR is considered in this section. 

In the ServiceUsageRequest, a monetary quota is passed to the Rating Function and the response contains the allowed 
service units for this monetary quota. 

The following figure describes the message flow for the service usage request method. The scenario describes the case 
where the SBCF invokes the ServiceUsageRequest method for charging several times during the same session, with 
reservation. 
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Figure : Service usage request method with reservation 
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Step 1: 
Step 2: 




Step 2' 


(Optiona 


Step 3: 




Step 4: 





Step 5: 
Step 6: 


Step 7: 


Step 8: 


Step 9: 


Step 10-14 
Step 15: 


Step 16: 
Step 17: 


Step 18: 
Step 19: 
Step 20: 



The SBCF receives an online charging request referring to an MS's bearer/session usage. 
The SBCF performs account balance reservation, based on the operator policy (typically the 
reservation will be service dependent). If there is insufficient balance, the available amount in the 
account balance is reserved. 
l):In case there is no existing subscriber's context, the SBCF creates a new subscriber's context 
information. Otherwise, the SBCF updates the existing subscriber's context and get the list of 
active services for the given subscriber. This Step only applies when correlation is enabled. 
The SBCF requests the allowed usage of this service (service units) for the given monetary quota 
(i.e. the amount reserved from the account balance). The SBCF provides also a minimal number of 
requested service units. 

The Rating Function retrieves the appropriate tariff to be applied for the bearer/session. It 
calculates the number of service units that are allowed for the given monetary quota. If the 
calculated number of service units is lower than the minimal number of requested units for this 
service, the minimal requested units will be used. The Rating Function reserves counter values if 
needed and calculates the price. Note that the price may be different than the given monetary units 
(e.g. the user has free units from this service or the given monetary quota was insufficient for the 
minimal requested units from this service). 

The Rating Function returns the allowed usage, price and tariff information to the SBCF. 
If the Rating Function has returned a price which is higher than the initial account balance 
reservation (e.g. for a premium service), the charging function makes another reservation to meet 
the returned price. 

Assuming a successful account balance reservation, the SBCF returns the granted units to the 
requesting network element. Otherwise the service is denied. 

When the granted units have been used, a new request is send from the network element to the 
SBCF. 

Based on the tariff information and the price received in step 5 and the amount already reserved 
(either in step 2 or 6), the SBCF performs another account balance reservation. 
Repeat steps 3-7 . 

The session ends and a final charging request is issued with updated session details (e.g. exact 
session length). 

The SBCF sends a final service usage request with a debit instruction. 

The Rating Function performs final rating for the consumed resources and adjusts the counters 
accordingly. 

The Rating Function returns the final price to the SBCF. 
Based on the received price, the SBCF performs final account control. 

Finally, the SBCF sends an acknowledgment message to the serving network node in order to 
terminate the online charging dialogue. 



In this scenario a service usage message request is send for every online charging request. The sequence of steps 8-13 
can be repeated multiple times. Between any repetitions of those sequences, the charging session parameters that are 
relevant for rating may change. The change can be solicited (e.g. tariff switch) or unsolicited (e.g. QoS change). The 
network element shall issue another charging request in those cases i.e. on expiry time if tariff switch occurred, when 
granted units are consumed or when the QoS is changed. In all those cases, the charging function, sends information on 
both, the passed quota and the new quota. Specifically, when a tariff switch occurred, the charging function shall pass 
the consumed units before and after to the tariff switch in the following tariff request method. The rating function 
adjusts the reserved counters if needed as a result from the new information from the SBCF. The rating function makes 
new counters reservations for the next quota and returns the allowed number of service units for the next quota. 

To allow for correct charging of this kind of scenarios, the rating function needs to make sure that all tariff information 
contained in a TariffResponse message expires between the next two tariff switches, i.e. between the tariff switch time 
that is defined within this TariffResponse message and the next subsequent tariff switch time. For this purpose, a 
parameter Expiry Time is used. The Expiry Time defines, how long the tariff information contained in the 
TariffResponse message is valid after the timestamp of the TariffRequest that triggered this response. For the handling 
of multiple tariff switches, it is recommended to set the Expiry Time to the difference between the next two tariff switch 
times. 

It should be noted that the ExpiryTime may also be used when no tariff switch is foreseen, to ensure a subsequent tariff 
retrieval operation after a specified time period has passed. 

The service usage request message contains the reserved monetary quota for the service. The monetary quota in the first 
service usage request message is predetermined in the SBCF (e.g. according to the service). The predetermined 
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monetary quota shall be designed to be sufficient for a minimal service usage. In some cases (e.g. premium services), 
setting the monetary quota to meet a minimal service usage can not be guaranteed. Hence, the first service usage request 
contains also a minimal number of service units required. The Rating Function retrieves the appropriate tariff and 
calculates the allowed number of service units. The number of service units is calculated as the maximum of the 
minimal requested units and the number of units that can be consumed for the given monetary quota. 

If the service is free of charge (e.g. the user has some free service units), the Rating Function may not allow the whole 
quantity at once. If the free service units are shared between several users, the rating function may break the allowed 
units to smaller quotas to enable sharing of the free service units between the users, based on the operators policy. The 
Rating Function returns also the accumulated price for the consumed service and the requested service in the current 
quota. The price is used by the Charging Function to determine if additional account balance reservation is needed. 

Service denial is being handled in the same manner as in the tariff request scenario (see subclause 6.2.2.2.2 for details). 
If the service was not delivered at all for any reason, an explicit service usage request with a release request subtype is 
send from the charging function to the rating function. 

After the first service usage request, subsequent service usage request messages can take into account the account 
balance and the applied tariff and try to optimize the monetary quota in order to minimize the number of service usage 
requests. The monetary quota is bounded by the account balance. Requesting service usage for a very low monetary 
quota can result in a small amount of granted service units. In this case, the SBCF may decide to deny the service and 
close the session with the actual number of service units consumed. 

The allowed units are calculated as if consumed in the highest tariff available for the subscriber (e.g. if the volume tariff 
is time dependent, the price will be calculated as if the volume was consumed solely during the higher rate period). If 
the tariff is not time dependent, but volume dependent, the tariff steps will be taken into account in advance. 

At the final service usage request message (with the debit indication), the counters are updated and the final service 
price is returned. The charging function is responsible to free any extra reservations made. 
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7 



Definition of charging information 



7.1 Re IVIessage Types and Formats 



7.1.1 



General guidelines 



7.1.1.1 



General Description of Data types and Message Formats 



The messages and data types used on the Re interface are defined based on the Diameter base protocol [401]. The 
contents of the messages is defined in subclause 7.1.2. Primitive data types are used as defined in the specification of 
the Diameter base protocol [401]. The structure of more complex data types is defined in subclause 7.1.3. Details on the 
Diameter implementation of the Re interface are described in subclause 7. 1 .4. 



7.1.1.2 



Rating Function Class selection 



Although the contents of the messages are almost identical, the handling of the messages in the Rating Function will be 
different depending on the class of Rating Function used in a network. To distinguish between both classes of Rating 
Functions, the parameter RequestSubType is used. 

If a "Class A" Rating Function is used, the parameter RequestSubType will not be present, because there are no 
subtypes in this case. 

If a "Class B" Rating Function is used, the parameter RequestSubType will always be present. 

7.1.2 Methods 

7.1.2.1 PriceRequest Method 

This request type is used to determine the price for a given event. 

The following tables indicate the contents of the PriceRequest and PriceResponse messages. 

The column "Status" denotes, whether the field is 'mandatory' (M), 'optional' (O) or "not applicable" (-). Optional means 
that this parameter shall in general be included if available; if special conditions apply in addition, then these 
conditions are described in the "Description" column. 

The body of the PriceRequest message consists of the following fields. 



Name 


Status in 
class 


Description 


Example 


■A' 


■B' 


SessionID 


M 


M 


Session identification, used to match the request / response. 




ActualTime 


M 


M 


Actual timestamp of the current request. 




Subscription- 
Id 


M 


M 


Identifies the Charged Party. 

This element contains one of the following; 

-MSISDN(E.1 64 format) 

-IMSI(E.21 2 format) 

-SIP-URL 

-NAI 

- private ID (i.e. operator specific). 

The Subscription-Id is described in subclause 7.1 .4.2.54. The definition is taken 

from IETF RRC 4006 [402]. 

Editor"s Note: Applicability of NAI for 3GPP needs to be checked. 




Service- 
Rating 


M 


M 


One or more service elements. If several services are rated with one request, this 
grouped element is included several times. The structure of Service-Rating element 
is described in subclause 7.1 .3.1 . 





ETSI 



3GPP TS 32.296 version 8.2.1 Release 8 



52 



ETSI TS 132 296 V8.2.1 (2009-01) 



The body of the PriceResponse message from the Rating Engine consists of the following fields: 



Name 


Status in 
class 


Description 


Example 


'A' 


■B' 


SessionID 


M 


M 


Session identification, used to matcli tlie request / response. 




Service- 
Rating 


M 


IVI 


One or more service elements. If several services are rated with one request, this 
grouped element is included several times. The structure of Service-Rating element 
is described in subclause 7.1 .3.1 . 





7.1.2.2 



TariffRequest Method 



The following tables indicate the contents of the TariffRequest and TariffResponse messages. 

The column "Status" denotes, whether the field is 'mandatory' (M), 'optional' (O) or "not applicable" (-). Optional means 
that this parameter shall in general be included if available; if special conditions apply in addition, then these 
conditions are described in the "Description" column. 

The body of the TariffRequest message consists of the following fields: 



Name 


Status in 
class 


Description 


Example 


■A' 


■B' 


SessionID 


M 


M 


Session identification, used to match the request / response. 




FirstRequest 








Indicates that this is the first TariffRequest within this rating dialogue. 




BeginTime 








Event-timestamp of service activation request. 




ActualTime 


M 


M 


Actual timestamp of the current request. 




Subscription- 
Id 


M 


M 


Identifies the Charged Party. 

This element contains one of the following; 

-MSISDN (E.I 64 format) 

-IMSI(E.21 2 format) 

-SIP-URL 

-NAI 

- private ID (i.e. operator specific). 

The Subscription-Id is described in subclause 7.1 .4.2.54. The definition is taken 

from IETF RRC 4006 [402]. 

Editor"s Note: AppUcability of NAI for 3GPP needs to be checked. 




Service- 
Rating 


M 


M 


One or more service elements. If several services are rated with one request, this 
grouped element is included several times. The structure of Service-Rating element 
is described in subclause 7.1 .3.1 . 





The body of the TariffResponse message from the Rating Engine consists of the following fields: 



Name 


Status in 
class 


Description 


Example 


'A' 


■B' 


SessionID 


M 


M 


Session identification, used to match the request / response. 




Service- 
Rating 


M 


M 


One or more service elements. If several services are rated with one request, this 
grouped element is included several times. The structure of Service-Rating element 
is described in subclause 7.1 .3.1 . 
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7.1.2.3 ServiceUsageRequest Method 

The ServiceUsageRequest Method is implemented only if Class B rating function is used. 

The following tables indicate the contents of the ServiceUsageRequest and ServiceUsageResponse messages. 

The column "Status" denotes, whether the field is 'mandatory' (M), 'optional' (O) or "not applicable" (-). Optional means 
that this parameter shall in general be included if available; if special conditions apply in addition, then these 
conditions are described in the "Description" column. 

The body of the ServiceUsageRequest message consists of the following fields: 



Name 


Status in 
class 


Description 


Example 


'A' 


■B' 


SessionID 


- 


M 


Session identification, used to match the request / response. 




BeginTime 


- 





Event-timestamp of service activation request. 




ActualTime 


- 


M 


Actual timestamp of the current request. 




Subscription- 
Id 




IVI 


Identifies the Charged Party. 

This element contains one of the following; 

-MSISDN(E.1 64 format) 

-IMSI(E.21 2 format) 

-SIP-URL 

-NAI 

- private ID (i.e. operator specific). 

The Subscription-Id is described in subclause 7.1 .4.2.54. The definition is taken 

from IETF RRC 4006 [402]. 

Editor"s Note: Apphcability of NAI for 3GPP needs to be checked. 




Service- 
Rating 


M 


M 


One or more service elements. If several services are rated with one request, this 
grouped element is included several times. The structure of Service-Rating element 
is described in subclause 7.1 .3.1 . 





The body of the ServiceUsageResponse message from the Rating Engine consists of the following fields: 



Name 


Status in 
class 


Description 


Example 


'A' 


■B' 


SessionID 


- 


M 


Session identification, used to match the request / response. 




Service- 
Rating 


M 


M 


One or more service elements. If several services are rated with one request, this 
grouped element is included several times. The structure of Service-Rating element 
is described in subclause 7.1 .3.1 . 
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7.1.3 Parameter Definitions 
7.1.3.1 Common Parameters 

The DestinationID type has the following structure: 



Name 


Status 


Description 


Example 


DestinationlDType 


M 


Type of Subscriber information contained in the DestinationlDData element. 
Supported are the following types: 
MSISDN, APN, URL, e-mail address,... 

Editor"s note: Further types are TBD. 




DestinationlDData 


M 


Identifies the destination, to which the requested service is directed. 
This element contains one of the following; 

- Number (E.164 format, e.g. MSISDN) 
-APN 

-URL 

- e-mail address 

- private ID (i.e. operator specific). 





The EParm type has the following structure: 



Name 


Status 


Description 


Example 


E-parameter E1 


M 


Refer to 3GPP TS 22.024 [201]. 




E-parameter E2 


M 


Refer to 3GPP TS 22.024 [201]. 




E-parameter E3 


M 


Refer to 3GPP TS 22.024 [201]. 




E-parameter E4 


M 


Refer to 3GPP TS 22.024 [201]. 




E-parameter E5 


M 


Refer to 3GPP TS 22.024 [201]. 




E-parameter E6 


M 


Refer to 3GPP TS 22.024 [201]. 




E-parameter E7 


M 


Refer to 3GPP TS 22.024 [201]. 





The Service-Rating type has the following structure: 
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Name 


Status 

in 
class 


Description 


Available 


■A' 


'B' 


PRQ 


PRS 


TRQ 


TRS 


SUQ 


sus 


Service- 
Identifier 


IVI 


M 


Identifies the service for which the online charging request was sent. 
If M-S-R AVP is not present, this AVP is mandatory. 


X 


X 


X 


X 


X 


X 


DestinationID 








The structure of an individual DestinationID element is described in 

subclause 7.1.3.1. 

Multiple occurrences of this element are possible. 


X 




X 




X 




Service- 
Information 








The structure of a Servicelnformation element is defined in the middle- 
tier documents and formally specified in TS 32.299 [50]. The content of 
this parameter corresponds to the service indicated by the 
Serviceldentifier. 


X 




X 








Extension 








Subscriber or operator-specific information, e.g. contract parameters. 
The format and content is out of scope for 3GPP standards. 


X 


X 


X 


X 


X 


X 


Counter 







One or multiple Counter elements. 

The structure of an individual Counter element is described in subclause 

7.1.3.2 


X 




X 








BasicPriceTime- 
Stamp 





- 


The timestamp of the last charging of the Basic Price, if applicable for the 
service indicated by the ServicelD. 


X 




X 








RequestSub- 
Type 


- 


M 


Request sub type as described in subclause 7.1 .3.3. 


X 




X 




X 




Price 


M 


M 


Price for the requested service. 




X 




X 




X 


Billinglnfo 








Textual description for bill presentation. 




X 




X 




X 


BasicPrice 





- 


Basic Price for the requested service, e.g. basic fee once per day. 




X 




X 






CounterPrice 





- 


One or multiple CounterPrice elements. The structure of an individual 
CounterPrice element is described in subclause 7.1 .3.2. 




X 










ImpactOn 
Counter 







Description of the impacted counters. This parameter is being used only 
in the result of a 

request with a debit request subtype. The structure of an individual 
impact on counter element is described in subclause 7.1 .3.3. Multiple 
occurrences of this element might be used. 




X 




X 




X 


RequestedUnits 







The number of requested units from the service. This parameter is 
mandatory in a request with reservation request subtype. 






X 








ConsumedUnits 







The total number of consumed units of the service since previous 
request. 






X 




X 




ConsumedUnits 
AfterTariffSwitch 







The number of consumed units of the service since previous request 
after tariff switch occurred. This parameter is mandatory if the tariff 
switch occurred since the previous request. 






X 




X 




TariffSwitch- 
Time 








Time in Seconds from the time in parameter ActualTime of the 

TariffRequest until a tariff switch occurs. 

'0' means immediately (the second set of e-parameters is valid). 








X 




X 


IVIonetaryTariff 


M 





E-parameters that are currently valid. Eparm type is defined in subclause 

7.1.3.1. 

Class "B": This parameter is mandatory in the response message after a 

request with reservation subtype. 








X 




X 


NextMonetary- 
Tariff 








E-parameters after the next TariffSwitch 
Eparm type is defined in subclause 7.1 .3.1 . 








X 




X 


Expiry Time 








Time period in seconds from the time in parameter ActualTime of the 

TariffRequest until the expiration of all tariff information contained in this 

TariffResponse message. 

This field may be used e.g. if multiple TariffSwitches are foreseen, or if 

interworking between limited valid units and TariffSwitches needs to be 

ensured. 








X 




X 


ValidUnits 








Defines for how many units the tariff is valid. 








X 






IVIonetaryTariff- 
AfterValidUnits 








E-parameters after all valid units have been used. 

Eparm type is defined in subclause 7.1 .3.1 . 

This field may be used to optimize service availability in scenarios with 

limited valid units. 








X 






CounterTariff 





- 


One or multiple CounterTariff elements. The structure of an individual 
CounterTariff element is described in subclause 7.1 .3.2. 








X 






Requested- 
Counter 







One or multiple CounterlDs. Only the counters identified in this list shall 
be included by the SBCF in subsequent TariffRequest messages within 
this session. The list is valid until a modified list is received by the SBCF 
or until the session ends. 








X 






IVIonetaryQuota 


- 





Number of monetary units reserved for the service usage. Mandatory in 
a reservation request subtype. 










X 




Minimal 
RequestedUnits 


- 





The minimal number of requested units from the service. This parameter 
Is mandatory in the first request with reservation request subtype. 










X 




AllowedUnits 







Defines how many units can be granted for this monetary quota. 
Returning the AllowedUnits is mandatory in the reservation and AoC 
request subtypes. 












X 
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7.1 .3.2 Class 'A' specific Parameters 

The Counter type has the following structure: 



Name 


Status 


Description 


Example 


CounterlD 


M 


Identifies the Counter (i.e. used to address the counter). 




CounterValue 





The actual current value of the Counter. 


17 


CounterExpiryDate 





Timestamp for the expiration date of the current counter value. 





The CounterPrice type has the following structure: 



Name 


status 


Description 


Example 


CounterlD 


M 


Identifies the Counter (i.e. used to address the counter). 




CounterType 





Operator specific value, for descriptive purposes. 




CounterChange 





Value with which the counter shall be incremented or decremented. 


-2 


SetCounterTo 





Value, to which the counter shall be set. 


50 


CounterExpiryDate 





Timestamp for the expiration date of the current counter value. 





The CounterTariff type has the following structure: 



Name 


Status 


Description 


Example 


CounterlD 


M 


Identifies the Counter (i.e. used to address the counter). 




CounterType 





Operator specific value, for descriptive purposes. 




CounterChange- 
PerSession 





Value, with which the counter shall be incremented or decremented for the whole 
session. 


4 


CounterChange- 
PerConsumedServiceUnit 





Value, with which the counter shall be incremented or decremented per consumed 
service unit. 


-1 


CounterChangeForFirst- 
ChargeableTimeUnit 





Value, with which the counter shall be incremented or decremented for the first 
chargeable unit (as defined by 
E-parameter E7 from MonetaryTariff). 


-2 


CounterChange- 
PerSubsequent- 
ChargeableTimeUnit 





Value, with which the counter shall be incremented or decremented per chargeable unit 

(as defined by 

E-parameter E2 from MonetaryTariff, i.e. except for the first unit). 


-1 


CounterChange- 
PerChargeableVolumeUnit 





Value, with which the counter shall be incremented or decremented per chargeable unit 

(as defined by 

E-parameter E6 from MonetaryTariff). 


3 


CounterChangeForFirst- 

ChargeableTimeUnitAfter- 

Switch 





Value, with which the counter shall be incremented or decremented for the first 
chargeable unit after a Tariff Switch has occurred (as defined by E-parameter E7 from 
NextMonetaryTariff). 


-4 


CounterChange- 
PerSubsequent- 
ChargeableTimeUnitAfter- 
Switch 





Value, with which the counter shall be incremented or decremented per chargeable unit 
after a Tariff Switch has occurred (as defined by E-parameter E2 from 
NextMonetaryTariff, i.e. except for the first unit). 


-1 


CounterChange- 
PerChargeable- 
VolumeUnitAfterSwitch 





Value, with which the counter shall be incremented or decremented per chargeable unit 
after a Tariff Switch has occurred (as defined by E-parameter E6 from 
NextMonetaryTariff). 


5 


CounterThreshold 





Threshold value for this counter. If this threshold is reached, all tariff information 
contained in this TariffResponse message expires, and the Charging Function shall sent 
a new TariffRequest message. 


30 


SetCounterTo 





Value, to which the counter shall be set. 


50 


CounterExpiryDate 





Timestamp for the expiration date of the current counter value. 





7.1 .3.3 Class 'B' specific Parameters 

The parameter Requests ubType can have the following values: 

• AoC - Advice of Charge. In this sub-type, there is no counter reservation and no counter updates by the Rating 
Function. 

• Reservation - This Price Request sub-type is used at event authorization time, prior to granting a service to a 
user. The Rating Function will reserve counters as needed according to the request. A Price Request with a Debit 
sub-type should follow after a service successful delivery or a Release sub-type in case the delivery failed. 

• Debit - This Price Request sub-type is issued when a session ends or a service was granted successfully to a user, 
in order to debit a previously reservation request. The Rating Function will free any unused portion of an 
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outstanding counter reservation. Note that multiple Price Requests with a Debit sub-type can be sent during a 
session for partial charging. 

• Release - This Price Request sub-type is issued when a service delivery failed to release a previously reserved 
amount. The Rating Function will free any outstanding counter reservation. 

The following tables summarize the parameters' presence in the various methods and messages. For each request 
subtype, the column denotes, whether the field is 'mandatory' (M), 'optional' (O) or "not applicable" (-). 

Parameter presence in the PriceRequest message: 



Name 


Reservation 


Debit 


Release 


SessionID 


M 


M 


M 


ActualTime 


M 


M 





Subscription-Id 


M 


- 


- 


Service-Identifier 


M 


- 


- 


DestinationID 








- 


Servicelnformation 








- 


Extension 











RequestSubType 


M 


M 


M 



Parameter presence in the PriceResponse message: 



Name 


Reservation 


Debit 


Release 


SessionID 


M 


M 


M 


Price 


M 


M 


M 


Billinglnfo 


- 








Extension 











BasicPrice 


- 


- 


- 


CounterPrice 


- 


- 


- 


ImpactOn 
Counter 


- 





- 



Parameter presence in the TariffRequest message: 



Name 


Reservation 


Debit 


Release 


SessionID 


M 


M 


M 


FirstRequest 


- 


- 


- 


Beginlime 





- 


- 


ActualTime 


M 


M 


M 


Subscription-Id 


M 


- 


- 


Service-Identifier 


M 


- 


- 


DestinationID 








- 


Servicelnformation 








- 


Extension 











Counter 


- 


- 


- 


BasicPriceTimeStamp 


- 


- 


- 


RequestSubType 


M 


M 


M 


RequestedUnits 


M 


- 


- 


ConsumedUnits 





M 


- 


ConsumedUnits 
AfterTariffSwitch 








- 



Parameter presence in the TariffResponse message: 
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Name 


Reservation 


Debit 


Release 


SessionID 


M 


M 


M 


TariffSwitchTime 





- 


- 


MonetaryTariff 


M 


- 


- 


NextMonetary Tariff 





- 


- 


ExpiryTime 





- 


- 


ValidUnits 





- 


- 


Monetary TariffAfterValidUnits 


- 


- 


- 


Billinglnfo 


- 





- 


Extension 











CounterTariff 


- 


- 


- 


RequestedCounter 


- 


- 


- 


BasicPrice 


- 


- 


- 


Price 


- 


M 


- 


ImpactOn 
Counter 


- 





- 



Parameter presence in the ServiceUsageRequest message: 



Name 


Reservation 


Debit 


Release 


SessionID 


M 


M 


M 


BeginTime 





- 


- 


ActualTime 


M 


- 


- 


Subscription-Id 


M 


M 


M 


Service-Identifier 


M 


- 


- 


DestinationID 








- 


Servicelnformation 








- 


IVIonetaryQuota 








- 


IVIinimal 
RequestedUnits 





- 


- 


Extension 











RequestSubType 


M 


M 


M 


ConsumedUnits 





M 


- 


ConsumedUnits 
AfterTariffSwitch 








- 



Parameter presence in the ServiceUsageResponse message: 



Name 


Reservation 


Debit 


Release 


SessionID 


M 


M 


M 


TariffSwitchTime 





- 


- 


IVIonetaryTariff 


M 


- 


- 


Next IVIonetary Tariff 





- 


- 


ExpiryTime 





- 


- 


AllowedUnits 





- 


- 


Price 


M 


M 


- 


Billinglnfo 


- 





- 


ImpactOn 
Counter 


- 





- 


Extension 


- 









The ImpactOnCounter type has the following structure: 



Name 


Status 


Description 


Example 


CounterlD 


M 


Identifies the Counter (i.e. used to address the counter). 




CounterValueBegin 





The counter value at the beginning of the online charging session. 


17 


CounterValueChange 


M 


The change in the counter value as result of the current online charging 
session. 


-4 


CounterValueEnd 





The counter value at the end of the online charging session. Note that this 
value may be different from the value at the beginning of the online charging 
session plus the value change in case of concurrent service consumption. 


11 
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7.1 .4 Diameter protocol specification 



The messages for the Re interface, their formats and their contents are defined in terms of the Diameter Rating 
AppHcation, a new 3GPP specific Diameter apphcation based on the Diameter base protocol [401]. The application ID 
for the Diameter Rating Application is tbd. 

Editor's Note: The application ID shall be defined by CN4, and shall be included in 3GPP TS 29.230. 

The messages for the Re interface are defined in the following subclause 7.1.4.1. These are new messages that are not 
included in the Diameter base protocol, however, relevant AVPs from the Diameter base protocol are included in the 
definition of these messages. Additional AVPs which are required for the functionality of the Re interface are also 
included. These additional AVPs are explained in detail in subclause 7.1.4.2. 

Editor's Note: We have to define Finite State Machines (for class "A" only for the OCFs, for class "B" for both, 
OCFs and RF)? 

Editor's Note: Error handling needs to be defined (separate subclause). 



7.1.4.1 



Diameter Rating messages on the Re interface 



The table below describes the use of messages on the Re interface. Details on the use of these messages can be found in 
subclause 6.2 of this document. 



Command-Name 


Source 


Destination 


Abbreviation 


Command-Code 


PriceRequest 


EBCF 


RF 


PRQ 




PriceResponse 


RF 


EBCF 


PRS 




TariffRequest 


SBCF 


RF 


IRQ 




TariffResponse 


RF 


SBCF 


TRS 




ServiceUsageRequest 


SBCF 


RF 


SUQ 




ServiceUsageResponse 


RF 


SBCF 


SUS 





Editor's Note: Command codes shall be defined by CN4, and shall be included in 3GPP TS 29.230. 

Editor's Note: Do we have to include (some of the) other messages defined in the Diameter base protocol? 

The following subclauses describe the structure of the individual messages on the Re interface. The descriptions are 
based directly on the format of the Accounting-Request and Accounting-Answer messages defined in the base Diameter 
protocol specification [401]. 

The following symbols are used in the tables: 

• <AVP> indicates a mandatory AVP with a fixed position in the message. 

• {AVP} indicates a mandatory AVP in the message. 

• [AVP] indicates an optional AVP in the message. 

• *AVP indicates that multiple occurrences of an AVP are possible. 
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7.1.4.1.1 PriceRequest message 

The Diameter PriceRequest message as used on the Re interface has the following structure. 

<PRQ> :: = <Diameter Header: xxx, REQ, PXY> 
<Session-ld> 
{Origin-Host} 
{Origin-Realm} 
{Destination-Realm} 
[Destination-Host] 
[Vendor-Specific-Application-ld] 
[User-Name] 
[Event-Timestamp] 
{ActualTime} 
{Subscription-Id} 
*{Service-Rating} 

Editor's Note: Check if all included AVPs from the Diameter base protocol are needed. 
Check if additional AVPs from the Diameter base protocol must be included. 

7.1.4.1.2 PriceResponse message 

The Diameter PriceResponse message as used on the Re interface has the following structure. 

<PRS> :: = <Diameter Header: xxx, PXY> 
<Session-ld> 
{Origin-Host} 
{Origin-Realm} 

[Vendor-Specific-Application-Id] 
[User-Name] 
[Event-Timestamp] 
*{Service-Rating} 

Editor's Note: Check if all included AVPs from the Diameter base protocol are needed. 
Check if additional AVPs from the Diameter base protocol must be included. 

7.1.4.1.3 Tariff Request message 

The Diameter TarifJRequest message as used on the Re interface has the following structure. 

<TRQ> :: = <Diameter Header: xxx, REQ, PXY> 
<Session-ld> 
{Origin-Host} 
{Origin-Realm} 
{Destination-Realm} 
[Destination-Host] 
[Vendor-Specific-Application-Id] 
[User-Name] 
[Event-Timestamp] 
[FirstRequest] 
[BeginTime] 
{ActualTime} 
{Subscription-Id} 
*{Service-Rating} 



Editor's Note: Check if all included AVPs from the Diameter base protocol are needed. 
Check if additional AVPs from the Diameter base protocol must be included. 
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7 AAA. 4 Tariff Response message 

The Diameter TarijfResponse message as used on the Re interface has the following structure. 

<TRS> :: = <Diameter Header: xxx, PXY> 
<Session-ld> 
{Origin-Host} 
{Origin-Realm} 

[Vendor-Specific-Application-ld] 
[User-Name] 
[Event-Timestamp] 
*{Service-Rating} 

Editor's Note: Check if all included AVPs from the Diameter base protocol are needed. 
Check if additional AVPs from the Diameter base protocol must be included. 

7.1.4.1.5 ServiceUsageRequest message 

The Diameter ServiceUsageRequest message as used on the Re interface has the following structure. 

<SUO> :: = <Diameter Header: xxx, REQ, PXY> 
<Session-ld> 
{Origin-Host} 
{Origin-Realm} 
{Destination-Realm} 
[Destination-Host] 
[Vendor-Specific-Application-ld] 
[User-Name] 
[Event-Timestamp] 
[BeginTime] 
{ActualTime} 
{Subscription-Id} 
*{Service-Rating} 

Editor's Note: Check if all included AVPs from the Diameter base protocol are needed. 
Check if additional AVPs from the Diameter base protocol must be included. 

Editor's Note: Check if the order of the AVPs is aligned with the tariff request. 

7.1.4.1.6 ServiceUsageResponse message 

The Diameter ServiceUsageResponse message as used on the Re interface has the following structure. 

<SUS> :: = <Diameter Header: xxx, PXY> 
<Session-ld> 
{Origin-Host} 
{Origin-Realm} 

[Vendor-Specific-Application-Id] 
[User-Name] 
[Event-Timestamp] 
*{Service-Rating} 

Editor's Note: Check if all included AVPs from the Diameter base protocol are needed. 
Check if additional AVPs from the Diameter base protocol must be included. 

Editor's Note: Check if the order of the AVPs is aligned with the tariff response. 
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7.1 .4.2 AVPs for Rating on the Re interface 

The use of the Attribute Value Pairs (AVPs) that are defined in the Diameter Base Protocol [401] is specified in 
subclause 7.1.4.1 for the Re interface. Detailed specification of these AVPs is available in the Diameter base protocol 
specification. 

Editor" s Note: 'The 3GPP Rating Application uses the value xxx (3GPP) as Vendor-Id.' - Do we need this ? 

Additional AVPs which are not included in the Diameter base protocol are used for rating purposes in all messages on 
the Re interface. The use of these AVPs is described in subclause 7.1.4.1. 

Detailed descriptions of AVPs that are used specifically for online rating are provided in the subclauses below the table. 
The table contains all AVPs used for the Diameter Rating application, in alphabetical order. For AVPs that are just 
borrowed from other applications only the reference is provided in the table below, and the detailed description is not 
repeated. 
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AVP Name AVP Code Data Type Description / Reference 


AVPs from Diameter base protocol 


[Destination-Host] 






[401] 


{Destination-Realm} 






[401] 


[Event-Timestamp] 






[401] 


{Origin-Host} 






[401] 


{Origin-Realm} 






[401] 


<Session-ld> 






[401] 


[User-Name] 






[401] 


[Vendor-Specific-Application-ld] 






[401] 


General Diameter Rating AVPs 


{ActualTime} 


TBD 


Time 


subclause ?.1.4.2.1 


[BeginTime] 


TBD 


Time 


subclause ?.1.4.2.5 


[FirstRequest] 


TBD 


Enumerated 


subclause ?.1.4.2.41 


*{Service-Rating} 


TBD 


Grouped 




{Service-Identifier} 


TBD 


UTFSString 


subclause ?.1.4.2.5S; [402] 


* [DestinationID] 


TBD 


Grouped 


subclause ?.1. 4. 2. 29 


{DestinationlDType} 


TBD 


Enumerated 


subclause ?.1. 4.2.31 


{DestinationlDData} 


TBD 


UTFSString 


subclause ?.1. 4.2.30 


[Servicelnformation] 


TBD 


Grouped 


Subclause 7.1.4.2.54 


[Extension] 


TBD 


Grouped 


subclause ?.1. 4.2.40 


[Price] 


TBD 


UnsignedS2 


Subclause?.!. 4.2.4S; 
mandatory in PRS, 
optional in TRS 


[Billinglnfo] 


TBD 


UTFSString 


subclause ?.1.4.2.6 


[TariffSwitchlime] 


TBD 


UnsignedS2 


subclause ?.1.4.2.59 


{IVIonetaryTariff} 


TBD 


Grouped 


subclause ?.1.4.2.44 


{EparameterEI} 


TBD 


lntegerS2 


subclause?. 1.4.2.32 


{EparameterE2} 


TBD 


lntegerS2 


subclause ?.1.4.2.3S 


{EparameterES} 


TBD 


lntegerS2 


subclause ?.1.4.2.34 


{EparameterE4} 


TBD 


lntegerS2 


subclause ?.1.4.2.3S 


{EparameterES} 


TBD 


lntegerS2 


subclause?. 1.4. 2. 36 


{EparameterES} 


TBD 


lntegerS2 


subclause?. 1.4.2.3? 


{EparameterE?} 


TBD 


lntegerS2 


subclause?. 1.4.2.38 


[NextlVlonetaryTariff] 


TBD 


Grouped 


subclause ?.1.4.2.4? 


{EparameterEI} 


TBD 


lntegerS2 


subclause?. 1.4.2.32 


{EparameterE2} 


TBD 


lntegerS2 


subclause?. 1.4. 2. 3S 


{EparameterES} 


TBD 


lntegerS2 


subclause?. 1.4.2.34 


{EparameterE4} 


TBD 


lntegerS2 


subclause ?.1.4.2.3S 


{EparameterES} 


TBD 


lntegerS2 


subclause?. 1.4. 2. 36 


{EparameterES} 


TBD 


lntegerS2 


subclause?. 1.4.2.3? 


{EparameterE?} 


TBD 


lntegerS2 


subclause?. 1.4. 2. 38 


[Expirylime] 


TBD 


UnsignedS2 


subclause ?.1. 4.2.39 


[ValidUnits] 


TBD 


UnsignedS2 


subclause ?.1. 4.2.60 


[MonetarylariffAfterValidUnits] 


TBD 


Grouped 


subclause ?.1.4.2.4S 


{EparameterEI} 


TBD 


lntegerS2 


subclause?. 1.4.2.32 


{EparameterE2} 


TBD 


lntegerS2 


subclause?. 1.4. 2. 3S 


{EparameterES} 


TBD 


lntegerS2 


subclause?. 1.4.2.34 


{EparameterE4} 


TBD 


lntegerS2 


subclause ?.1.4.2.3S 


{EparameterES} 


TBD 


lntegerS2 


subclause?. 1.4. 2. 36 


{EparameterES} 


TBD 


lntegerS2 


subclause?. 1.4.2.3? 


{EparameterE?} 


TBD 


lntegerS2 


subclause?. 1.4. 2. 38 


{Subscription-Id} 


TBD 


Grouped 


subclause ?.1.4.2.56 


{Subscription-Id-Type} 


TBD 


Enumerated 


subclause ?. 1.4. 2. 58 


{Subscription-Id-Data} 


TBD 


UTFSString 


subclause?. 1.4.2.5?; [402] 


Class A specific Diameter Rating AVPs 


'{Service-Rating} 


TBD 


Grouped 




* [Counter] 


TBD 


Grouped 


subclause ?.1.4.2.9 


{CounterlD} 


TBD 


UnsignedS2 


subclause ?.1. 4.2.20 


[CounterValue] 


TBD 


lntegerS2 


subclause?. 1.4. 2. 2S 


[CounterExpiryDate] 


TBD 


Time 


subclause ?.1. 4.2.19 


[BasicPriceTimeStamp] 


TBD 


Time 


subclause ?.1.4.2.4 


[BasicPrice] 


TBD 


UnsignedS2 


subclause ?.1.4.2.3 


* [CounterPrice] 


TBD 


Grouped 


subclause ?.1. 4.2.21 


{CounterlD} 


TBD 


UnsignedS2 


subclause ?.1. 4.2. 20 
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[CounterType] 


TBD 


Unsigned32 


subclause 7.1.4.2.24 


[CounterChange] 


TBD 


Integer32 


subclause 7.1.4.2.10 


[SetCounterTo] 


TBD 


Integer32 


subclause 7.1.4.2.55 


[CounterExpiryDate] 


TBD 


Time 


subclause 7.1.4.2.19 


* [CounterTariff] 


TBD 


Grouped 


subclause 7.1.4.2.22 


{CounterlD} 


TBD 


Unsigned32 


subclause 7.1.4.2.20 


[CounterType] 


TBD 


Unsigned32 


subclause 7.1.4.2.24 


[CounterChangePerSession] 


TBD 


Integer32 


subclause 7.1.4.2.16 


[CounterChangePerConsumed ServiceUnit] 


TBD 


Integer32 


subclause 7.1.4.2.15 


[CounterChangeForFirstChargeableTimeUnit] 


TBD 


Integer32 


subclause 7.1.4.2.11 


[CounterChangePerSubsequent 
ChargeableTimeUnit] 


TBD 


Integer32 


subclause 7.1.4.2.17 


[CounterChangePerChargeableVolumeUnit] 


TBD 


Integer32 


subclause 7.1.4.2.13 


[CounterChangeForFirst 
ChargeableTimeUnitAfterSwitch] 


TBD 


Integer32 


subclause 7.1.4.2.12 


[CounterChangePerSubsequent 
ChargeableTimeUnitAfterSwitch] 


TBD 


Integer32 


subclause 7.1.4.2.18 


[CounterChangePerChargeable 
VolumeUnitAfterSwitch] 


TBD 


Integer32 


subclause 7.1.4.2.14 


[CounterThreshold] 


TBD 


Integer32 


subclause 7.1.4.2.23 


[SetCounterTo] 


TBD 


Integer32 


subclause 7.1.4.2.55 


[CounterExpiryDate] 


TBD 


Time 


subclause 7.1.4.2.19 


* [RequestedCounters] 


TBD 


Unsigned32 


subclause 7.1.4.2.50 


Class B specific Diameter Rating AVPs | 


*{Service-Rating} 


TBD 


Grouped 




[RequestSubType] 


TBD 


Enumerated 


subclause 7.1.4.2.52 


[ImpactonCounter] 


TBD 


Grouped 


subclause 7.1.4.2.42 


{CounterlD} 


TBD 


Unsigned32 


subclause 7.1.4.2.20 


[CounterValueBegin] 


TBD 


Integer32 


subclause 7.1.4.2.26 


[CounterValueChange] 


TBD 


Integer32 


subclause 7.1.4.2.27 


[CounterValueEnd] 


TBD 


Integer32 


subclause 7.1.4.2.28 


[RequestedUnits] 


TBD 


Unsigned32 


subclause 7.1.4.2.51 


[ConsumedUnits] 


TBD 


Unsigned32 


subclause 7.1.4.2.7 


[ConsumedUnitsAfterTariffSwitch] 


TBD 


Unsigned32 


subclause 7.1.4.2.8 


[MonetaryQuota] 


TBD 


Unsigned32 


subclause 7.1.4.2.46 


[MinimalRequestedUnits] 


TBD 


Unsigned32 


subclause 7.1.4.2.43 


[AllowedUnits] 


TBD 


Unsigned32 


subclause 7.1.4.2.2 



Editor's Note: AVP codes shall be defined by CN4, and shall be included in 3GPP TS 29.230. 

Editor's Note; Check if definitions of some AVPs can be replaced by reference to IETF RRC 4006 [402]. 



7.1.4.2.1 



ActualTime AVP 



The ActualTime AVP is of type Time. It contains the actual timestamp of the current rating request message (i.e. PRQ 
or TRQ). 

Editor's Note: Is this AVP necessary, or is the content equal to the Event-Timestamp AVP from Diameter base? 



7.1.4.2.2 



AllowedUnits AVP 



The AllowedUnits AVP is of type Unsigned32. It defines how many service units the charging function can grant for 
the MonetaryQuota reserved. 



7.1.4.2.3 



BasicPrice AVP 



The BasicPrice AVP is of type Unsigned32. It contains a basic fee, that is applicable e.g. only once per day. If the 
BasicPrice AVP is received by an online charging function, the charging function will deduct this price from the 
subscriber's Account Balance, and it will store the current system time internally as timestamp for the last charging of 
the Basic Price. 
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7.1 .4.2.4 BasicPriceTimeStamp AVP 

The BasicPriceTimeStamp AVP is of type Time. It contains the timestamp of the last charging of the Basic Price which 
is appHcable for the service indicated in the current request. 

7.1.4.2.5 BeginTimeAVP 

The BeginTime AVP is of type Time. It contains the timestamp of the service activation request from the network. 

7.1.4.2.6 Billinglnfo AVP 

The Billinglnfo AVP is of type UTFSString. It contains billing relevant information. The content of this AVP is 
operator specific and out of scope for 3GPP standards. 

7.1.4.2.7 ConsumedUnits AVP 

The ConsumedUnits AVP is of type Unsigned32. It defines how many service units were totally consumed since the 
previous TRQ or SUQ message. This information is being used by the RF to update counters and track the price. 

7.1.4.2.8 ConsumedUnitsAfterTariffSwitch AVP 

The ConsumedUnitsAfterTariffSwitch AVP is of type Unsigned32. It defines how many service units were totally 
consumed after tariff switch since the previous TRQ or SUQ message. If no tariff switch occurred, the value shall be 
used. This information is being used by the RF to update counters and track the price. 

7.1.4.2.9 Counter AVP 

The Counter AVP is of type Grouped. It contains information related to a specified counter of the subscriber, as stored 
in the Account Balance Management Function. Multiple Counter AVPs can be included in one rating request message 
(i.e. PRQ or TRQ). 

The Counter AVP has the following format: 

Counter :: = < AVP Header: TBD> 
{CounterlD} 
[CounterValue] 
[CounterExpiryDate] 

7.1.4.2.10 CounterChange AVP 

The CounterChange AVP is of type Integer32. It contains the value, with which the addressed counter (as identified by 
the associated CounterlD AVP) shall be incremented or decremented. 

7.1 .4.2.1 1 CounterChangeForFirstChargeableTimeUnit AVP 

The CounterChangeForFirstChargeableTimeUnit AVP is of type Integer32. It contains the value, with which the 
addressed counter (as identified by the associated CounterlD AVP) shall be incremented or decremented for the first 
chargeable time unit. The first chargeable time unit is defined by the EParameterE? AVP in the MonetaryTariff AVP. 

7.1 .4.2.12 CounterChangeForFirstChargeableTimeUnitAfterSwitch AVP 

The CounterChangeForFirstChargeableTimeUnitAfterSwitch AVP is of type Integer32. It contains the value, with 
which the addressed counter (as identified by the associated CounterlD AVP) shall be incremented or decremented for 
the first chargeable time unit, if a tariff switch has occurred immediately at the beginning of the online charging session. 
In this case, the first chargeable time unit is defined by the EParameterE? AVP in the NextMonetaryTariff AVP. 
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7.1.4.2.13 CounterChangePerChargeableVolumeUnit AVP 

The CounterChangePerChargeableVolumeUnit AVP is of type Integer32. It contains the value, with which the 
addressed counter (as identified by the associated CounterlD AVP) shall be incremented or decremented per chargeable 
volume unit. The chargeable volume unit is defined by the EParameterE6 AVP in the MonetaryTariff AVP. 

7.1.4.2.14 CounterChangePerChargeableVolumeUnitAfterSwitch AVP 

The CounterChangePerChargeableVolumeUnitAfterSwitch AVP is of type Integer32. It contains the value, with which 
the addressed counter (as identified by the associated CounterlD AVP) shall be incremented or decremented per 
chargeable volume unit after a tariff switch has occurred. The chargeable volume unit is defined by the EParameterE6 
AVP in the NextMonetaryTariff AVP. 

7.1.4.2.15 CounterChangePerConsumedServiceUnit AVP 

The CounterChangePerConsumedServiceUnit AVP is of type Integer32. It contains the value, with which the addressed 
counter (as identified by the associated CounterlD AVP) shall be incremented or decremented per consumed service 
unit. 

7.1.4.2.16 CounterChangePerSession AVP 

The CounterChangePerSession AVP is of type Integer32. It contains the value, with which the addressed counter (as 
identified by the associated CounterlD AVP) shall be incremented or decremented once for the whole online charging 
session. 

7.1.4.2.17 CounterChangePerSubsequentChargeableTimeUnit AVP 

The CounterChangePerSubsequentChargeableTimeUnit AVP is of type Integer32. It contains the value, with which the 
addressed counter (as identified by the associated CounterlD AVP) shall be incremented or decremented per chargeable 
time unit, except for the first chargeable time unit. The chargeable time unit is defined by the EParameterE2 AVP in the 
MonetaryTariff AVP. 

7.1.4.2.18 CounterChangePerSubsequentChargeableTimeUnitAfterSwitch AVP 

The CounterChangePerSubsequentChargeableTimeUnitAfterSwitch AVP is of type Integer32. It contains the value, 
with which the addressed counter (as identified by the associated CounterlD AVP) shall be incremented or decremented 
per chargeable time unit (except for the first chargeable time unit) after a tariff switch has occurred. In this case, the 
chargeable time unit is defined by the EParameterE2 AVP in the NextMonetaryTariff AVP. 

7.1.4.2.19 CounterExpiryDate AVP 

The CounterExpiryDate AVP is of type Time. It contains the timestamp, at which the current value of the addressed 
counter (as identified by the associated CounterlD AVP) expires. 

7.1.4.2.20 CounterlD AVP 

The CounterlD AVP is of type Unsigned32. It is used to address a specific counter, i.e. it identifies the counter. 
Therefore, the CounterlD must be unique for each subscriber. 

7.1.4.2.21 CounterPrice AVP 

The CounterPrice AVP is of type Grouped. It is used in the PriceResponse message, and it contains information on how 
the online charging function shall modify a specified counter of the subscriber in the Account Balance Management 
Function. 

The CounterPrice AVP has the following format: 

CounterPrice :: = < AVP Header: TBD> 
{CounterlD} 
[Counterlype] 
[CounterChange] 
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[SetCounterTo] 
[CounterExpiryDate] 
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7.1 .4.2.22 CounterTariff AVP 

The CounterTariff AVP is of type Grouped. It is used in the TariffResponse message, and it contains information on 
how the online charging function shall modify a specified counter of the subscriber in the Account Balance 
Management Function. 

The CounterTariff AVP has the following format: 

CounterTariff :: = < AVP Header: TBD> 
{CounterlD} 
[CounterType] 

[CounterChangePerSession] 
[CounterChangePerConsumedServiceUnit] 
[CounterChangeForFirstChargeableTimeUnit] 
[CounterChangePerSubsequentChargeableTimeUnit] 
[CounterChangePerChargeableVolumeUnit] 
[CounterChangeForFirstChargeableTimeUnitAfterSwitch] 
[CounterChangePerSubsequentChargeableTimeUnitAfterSwitch] 
[CounterChangePerChargeableVolumeUnitAfterSwitch] 
[CounterThreshold] 
[SetCounterTo] 
[CounterExpiryDate] 

7.1.4.2.23 CounterThreshold AVP 

The CounterThreshold AVP is of type Integer32. It contains a threshold value for the addressed counter (identified by 
the associated CounterlD AVP). If the value of the specified counter reaches this threshold value, all tariff information 
contained in the TRS message expires, and the Online Charging Function shall sent a new TRQ message to the Rating 
Function. 

7.1 .4.2.24 CounterType AVP 

The CounterType AVP is of type Unsigned32. It contains an operator specific value which characterizes the addressed 
counter (identified by the associated CounterlD AVP). The CounterType AVP is used only for descriptive purposes. In 
contrast to the CounterlD AVP, the CounterType AVP may be not unique. 

7.1.4.2.25 CounterValue AVP 

The CounterValue AVP is of type Integer32. It contains the actual current value for the addressed counter (identified by 
the associated CounterlD AVP) as stored in the Account Balance Management Function. 

7.1.4.2.26 CounterValueBegin AVP 

The CounterValueBegin AVP is of type Integer32. It contains the value for the addressed counter (identified by the 
associated CounterlD AVP) at the beginning of the current onhne charging session. 

7.1.4.2.27 CounterValueChange AVP 

The CounterValueChange AVP is of type Integer32. It contains the change of the value for the addressed counter 
(identified by the associated CounterlD AVP) as result of the current online charging session. 

7.1.4.2.28 CounterValueEnd AVP 

The CounterValueEnd AVP is of type Integer32. It contains the value for the addressed counter (identified by the 
associated CounterlD AVP) at the end of the current online charging session. 
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7.1.4.2.29 DestinationID AVP 

The DestinationID AVP is of type Grouped. It contains information about the destination of the service usage in the 
network (e.g. the called party in a telephony scenario). Multiple Destination AVPs can be included in one rating request 
message (i.e. PRQ or TRQ), if the service is directed towards multiple destinations (e.g. one SMS to multiple 
recipients). 

The DestinationID AVP has the following format: 

DestinationID :: = < AVP Header: TBD> 
{DestinationlDType} 
{DestinationlDDataj 

7.1.4.2.30 DestinationlDDataAVP 

The DestinationlDData AVP is of type UTFSString. Its contents identify the destination to which the requested service 
is directed (e.g. the called party in a telephony scenario, the recipient of an SMS, ...). The DestinationlDType AVP 
defines which type of identifier is used. 

If an APN is included in the DestinationlDData AVP, it should be noted that 3GPP TS 23.003 [203] defines the APN 
with a maximum length of 100 octets, but 3GPP TS 29.002 [204] uses a length of 63. 

7.1 .4.2.31 DestinationlDType AVP 

The DestinationlDType AVP is of type Enumerated. It is used inside the DestinationID AVP, and it indicates which 
kind of destination information is contained in this DestinationlDData AVP. 

The following values are currently defined for the DestinationlDType AVP: 



Destination_Number 
Destination_APN 
Destination_URL 
Destination_EmailAddress 
Destination PrivatelD 



7.1.4.2.32 EParameterEI AVP 

The EParameterEI AVP is of type Integer32. It contains the Charge Advice Information Element el ("e-parameter el") 
as defined in 3GPP TS 22.024 [201]. 

7.1.4.2.33 EParameterE2 AVP 

The EParameterE2 AVP is of type Integer32. It contains the Charge Advice Information Element e2 ("e-parameter e2") 
as defined in 3GPP TS 22.024 [201]. 

7. 1 .4.2.34 EParameterE3 AVP 

The EParameterE3 AVP is of type Integer32. It contains the Charge Advice Information Element e3 ("e-parameter e3") 
as defined in 3GPP TS 22.024 [201]. 

7.1 .4.2.35 EParameterE4 AVP 

The EParameterE4 AVP is of type Integer32. It contains the Charge Advice Information Element e4 ("e-parameter e4") 
as defined in 3GPP TS 22.024 [201]. 

7. 1 .4.2.36 EParameterES AVP 

The EParameterES AVP is of type Integer32. It contains the Charge Advice Information Element e5 ("e-parameter e5") 
as defined in 3GPP TS 22.024 [201]. 
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7. 1 .4.2.37 EParameterE6 AVP 

The EParameterE6 AVP is of type Integer32. It contains the Charge Advice Information Element e6 ("e-parameter e6") 
as defined in 3GPP TS 22.024 [201]. 

7.1 .4.2.38 EParameterE7 AVP 

The EParameterE? AVP is of type Integer32. It contains the Charge Advice Information Element e7 ("e-parameter e7") 
as defined in 3GPP TS 22.024 [201]. 

7.1.4.2.39 ExpiryTime AVP 

The ExpiryTime AVP is of type Unsigned32. It is used in the TRS message. It contains the time period in seconds from 
the time included in the ActualTime AVP of the corresponding TRQ message until all tariff information contained in 
this TRS message expires. 

The online charging function shall start a timer whenever a TRQ message is sent (i.e. at the timestamp indicated in the 
ActualTime AVP of the TRQ message). When this timer reaches the value indicated in the ExpiryTime AVP of the 
TRS message that is received in response, the online charging function shall send a new TRQ message to the Rating 
Function. 

7.1.4.2.40 Extension AVP 

The Extension AVP is of type Grouped. Its purpose is to allow transmission of additional information elements not 
covered by this document, in order to meet operator-specific requirements. 

The format and the contents of this AVP are vendor- and/or operator-specific. The definition of this AVP is out of scope 
for 3GPP standards. 

Note that the format of the Extension AVP may be different in the various messages of the Diameter Rating Application 
(i.e. PRQ, PRS, TRQ, TRS). 

Editor's Note: Check if the notation "* [AVP]" can be used alternatively. 

7.1.4.2.41 FirstRequest AVP 

The FirstRequest AVP is of type Enumerated. Its purpose is to indicate, whether this TariffRequest message is the first 
Tariff Request message within this rating dialogue, i.e. this message "initiates" the rating dialogue. 

The following values are defined for the FirstRequest AVP: 

0: Subsequent Request: 

this is not tine first Tariff Request message witinin tinis rating dialogue 
1 : First Request: 

tinis is tine first Tariff Request message in tinis rating dialogue 

If the FirstRequest AVP is not included in a TariffRequest message, this shall be interpreted as a FirstRequest AVP set 
to "0", i.e. the TariffRequest is not the first request in this rating dialogue. 

7.1.4.2.42 ImpactOnCounter AVP 

The ImpactOnCounter AVP is of type Grouped. It contains information on how the counter has been modified as a 
result of the current online session. It is used by the Charging Data Function for inclusion in the CDRs (refer to 
subclause 7.2). 

The ImpactOnCounter AVP has the following format: 

ImpactOnCounter:: = < AVP Header: TBD> 
{CounterlD} 
[CounterValueBegin] 
{CounterValueChange} 
[CounterValueEnd] 
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7.1 .4.2.43 MinimalRequestedUnits AVP 

The MinimalRequestedUnits AVP is of type Unsigned32. It defines the minimal number of service units the charging 
function intends to grant. This information is being used by the RF to calculate the allowed units and to reserve 
counters. 

7.1 .4.2.44 MonetaryTariff AVP 

The MonetaryTariff AVP is of type Grouped. It is used in the TariffResponse message, and it contains the currently 
valid tariff information (i.e. the e-parameters that are valid at the time, when the TRS message is sent). 

The MonetaryTariff AVP has the following format: 

MonetaryTariff :: = < AVP Header: TBD> 

{EParameterEI} 
{EParameterE2} 
{EParameterES} 
{EParameterE4} 
{EParameterES} 
{EParameterE6} 
{EParameterE?} 

7.1 .4.2.45 MonetaryTariff AfterValidUnits AVP 

The MonetaryTariff AfterValidUnits AVP is of type Grouped. It is used in the TariffResponse message, and it contains 
the tariff information (i.e. the e-parameters) that is valid after all valid units (as indicated in the ValidUnits AVP) have 
been used. This AVP may be used to optimize service availabihty in call scenarios involving a limited number of valid 
units (ref to subsection 6.2.1.2.3 for details). 

The MonetaryTariffAfterValidUnits AVP may only be included in a TRS message, if the ValidUnits AVP is also 
included in the same message. 

The MonetaryTariffAfterValidUnits AVP has the following format: 

MonetaryTariffAfterValidUnits :: = < AVP Header: TBD> 

{EParameterEI} 
{EParameterE2} 
{EParameterES} 
{EParameterE4} 
{EParameterES} 
{EParameterES} 
{EParameterE?} 

7.1 .4.2.46 MonetaryQuota AVP 

The MonetaryQuota AVP is of type Unsigned32. It defines the amount of monetary units reserved by the charging 
function. The rating function calculates the amount of service units that can be consumed with this amount. 
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7.1.4.2.47 Service-Rating AVP 

The Service-Rating AVP is of type Grouped. It is used in the all messages once if single service is rated or multiple 
times if several services are rated in a single transaction. 

The Service-Rating AVP has the following format: 

Service-Rating :: = < AVP Header: TBD> 

{ Service-Identifier} 
*[DestinationID] 
[Servicelnformation] 
[Extension] 
[Price] 
[Bilhnglnfo] 
[Tariffs witchTime] 
{ MonetaryTariff } 
[NextMonetaryTariff] 
[Expiry Time] 
[ValidUnits] 
[MonetaryTariff AfterValidUnits] 

* [Counter] 
[BasicPriceTimeStamp] 
[BasicPrice] 

* [CounterPrice] 

* [CounterTariff] 

* [RequestedCounters] 
[Requests ubType] 
[ImpactonCounter] 
[RequestedUnits] 
[ConsumedUnits] 

[ConsumedUnitsAfterTariffSwitch] 
[MonetaryQuota] 
[MinimalRequestedUnits] 
[AUowedUnits] 



7.1 .4.2.48 NextMonetaryTariff AVP 

The NextMonetaryTariff AVP is of type Grouped. It is used in the TariffResponse message, and it contains the tariff 
information (i.e. the e-parameters) that is valid after a tariff switch has occurred (as indicated in the TariffSwitchTime 
AVP). 

The NextMonetaryTariff AVP may only be included in a TRS message, if the TariffSwitchTime AVP is also included 
in the same message. 

The NextMonetaryTariff AVP has the following format: 

NextMonetaryTariff :: = < AVP Header: TBD> 

{EParameterEI} 
{EParameterE2} 
{EParameterES} 
{EParameterE4} 
{EParameterES} 
{EParameterE6} 
{EParameterE7} 

7.1.4.2.49 Price AVP 

The Price AVP is of type Unsigned32. It contains the price of the requested service. 
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7.1.4.2.50 RequestedCounter AVP 

The RequestedCounter AVP is of type Unsigned32. An individual RequestedCounter AVP contains the ID of a counter 
(ref 7.1.4.2.19). Multiple RequestedCounter AVPs may be included in one TRS message. 

Only counters with CounterlDs included as a RequestedCounter AVP in a TRS message shall be included by the online 
charging function in subsequent TRQ messages within this session. The list of RequestedCounters is valid until a 
modified list is received by the online charging function in a subsequent TRS message or until the online charging 
session ends (i.e. if the list of requested counters does not change during the online charging session, the 
RequesedCounter AVPs must only be included in the first TRS message during this online charging session). 

7.1 .4.2.51 RequestedUnits AVP 

The RequestedUnits AVP is of type Unsigned32. It defines how many service units the charging function intends to 
grant. This information is being used by the RF to reserve counters. 

7.1 .4.2.52 RequestSubType AVP 

The RequestSubType AVP is of type Enumerated. It is used when class "B" rating function is used (for details see 
subclause 7.1.3.3). 

The following values are currently defined for the RequestSubType AVP: 



REQ_SUBTYPE_AOC 
REQ_SUBTYPE_RESERVE 
REQ_SUBTYPE_DEBIT 
REQ SUBTYPE RELEASE 



7.1 .4.2.53 Service- Identifier AVP 

Refer to IETF RRC 4006 [402] for details. 

7.1.4.2.54 Servicelnformation AVP 

The Servicelnformation AVP is defined in 3GPP TS 32.299. 

Note that the Location Information is included inside the Service Information AVP. 

7.1 .4.2.55 SetCounterTo AVP 

The SetCounterTo AVP is of type Integer32. It contains a value, to which the addressed counter (as identified by the 
associated CounterlD AVP) shall be set. This AVP may be used, e.g., to reset counters. 

Using the SetCounterTo AVP, the Rating Function can also trigger the creation of new counters: if the addressed 
counter does not exist, the Charging Function shall create this counter in the Account Balance Management Function 
and initialize it with the value contained in the SetCounterTo AVP. 

7.1.4.2.56 Subscription-Id AVP 

The Subscription-Id AVP is of type Grouped. It contains information which identifies the subscriber, to which the 
online charging session applies (i.e. the charged party). 

The SubscriberlD AVP has the following format: 

Subscription-ID :: = < AVP Header: TBD> 
{Subscription-Id-Type} 
{Subscription-Id-Data} 

Refer to IETF RRC 4006 [402] for details. 
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7. 1 .4.2.57 Subscription-Id-Data AVP 

Refer to IETF RRC 4006 [402] for details. 

7.1 .4.2.58 Subscription-Id-Type AVP 

The Subscription-Id-Type AVP is of type Enumerated. It is used inside the Subscription-Id AVP, and it indicates which 
kind of subscriber information is contained in this Subscription-Id AVP. 

The following values are currently defined for the Subscription-Id-Type AVP: 



END_USER_E164 
END_USER_IMSI 
END_USER_SIP_URI 
END_USER_NAI 
END USER PRIVATE 



Refer to IETF RRC 4006 [402] for details. 

7. 1 .4.2.59 TariffSwitchTime AVP 

The TariffSwitchTime AVP is of type Unsigned32. It is used in the TRS message. It contains the time period in seconds 
from the time included in the ActualTime AVP of the corresponding TRQ message until the next tariff switch occurs. A 
value "0" of the TariffSwitchTime AVP means, that the tariff switch occurs immediately, i.e. the tariff information 
contained in the NextMonetaryTariff AVP is valid immediately. 

7.1.4.2.60 ValidUnits AVP 

The ValidUnits AVP is of type Unsigned32. It is used in the TRS message. It defines, for how many consumed service 
units the tariff information in this TRS message is valid. After the number of units defined in the ValidUnits AVP has 
been consumed by the subscriber, the online charging function shall send a new TRQ message to the Rating Function. If 
available, the online charging function may use the MonetaryTariffAfterValidUnits AVP to charge service consumption 
after all valid units have been consumed (ref to subsection 6.2.1.2.3 for details). 
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7.2 OCS Charging data records 



Only general requirements on the generation and the contents of OCS CDRs are described in the present document. The 
detailed implementation is vendor specific and may be standardized in a later release. 

7.2.1 General description 

OCS charging data records (CDRs) are created in the Charging Data Function (CDF), which is always integrated in the 
Online Charging Functions (i.e. EBCF, SBCF). The generation of an OCS CDR is triggered by the first incoming online 
charging request from the network. The record remains open during the complete online charging session. It is closed 
after the final online charging response is sent from the OCF to the network (refer to subsection 6.2 for a definition of 
online charging request and online charging response). Partial records may be supported for some scenarios, e.g. for 
packet switched bearer charging. 

OCS CDRs are transferred immediately from the CDF to the Charging Gateway Function (CGF) via the Ga reference 
point. The CGF forwards CDRs via the Bo reference point to the operator's post-processing systems. 

The following types of OCS charging data records shall be supported: 

1 . in the scope of bearer level charging: 

• OCS CDR(s) for CS Charging 

• OCS CDR(s) for PS Charging 

• OCS CDR(s) for WLAN Charging 

Note that bearer level charging also covers SMS. 

2. in the scope of subsystem level charging: 

• OCS CDR(s) for IMS Charging 

3. in the scope of service (event) level charging: 

• OCS CDR(s) for MMS Charging 

• OCS CDR(s) for LCS Charging 

• OCS CDR(s) for PoC Charging 

• OCS CDR(s) for MBMS Charging 

• OCS CDR(s) for SMS Charging 

• OCS CDR(s) for MMTel Charging 

Additional CDRs may be supported for further services. 

OCS records include only data from the incoming online charging requests and internal data from the OCS. The 
following charging data are required in CDRs (if applicable for the online charging session): 

data relevant for charging from CAP messages (InitialDP, ApplyChargingReport, ...) 

data relevant for charging from Ro messages (Credit Control Request) 

tariff information received from the Rating Function 

call / session charges 

account balance at the end of the online charging session 

counter values at the beginning and at the end of the online charging session; optionally also the change of 
counter values that occurred due to the specific online charging session. 
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Note that inclusion of the change of counter values is especially important, when multiple online charging 
sessions can occur in parallel (e.g. when counters are shared among several subscribers). 

It is not required that the OCS collects further information from systems outside the OCS just for inclusion in the 
records. 

The Charging Gateway Function can be integrated with each of the Charging Functions (SBCF, EBCF), because all 
data necessary for the generation of OCS CDRs is already available in the Charging Functions. 

OCS CDR files are transferred from the Charging Gateway Function to the operator's post-processing systems via the 
Bo reference point (see [1], [52] for details). 



ETSI 



3GPP TS 32.296 version 8.2.1 Release 8 77 ETSI TS 132 296 V8.2.1 (2009-01) 



Annex A (informative): 
Bibliography 

a) 3GPP charging specifications 



3GPP TS 32.250: "Telecommunication management; Charging management; Circuit Switched 
(CS) domain charging". 

3GPP TS 32.298: "Telecommunication management; Charging management; Charging Data 
Record (CDR) parameter description". 

b) Common 3GPP specifications 

c) Other Domain and Service specific 3GPP / ETSI specifications 

d) Relevant ITU Recommendations 

e) Relevant IETF RFCs 



ETSI 



3GPP TS 32.296 version 8.2.1 Release 8 



78 



ETSI TS 132 296 V8.2.1 (2009-01) 



Annex B (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


R 


Subject/Comment 


Cat 


Old 


New 


Dec 2006 


SP-34 


SP-060714 


0006 


-- 


Update of Flow Based Charging for PCC - Align with 23.203 


F 


6.3.0 


7.0.0 


Sep 2007 


SP-37 


SP-070619 


0006a 


-- 


Introduce online charging correlation 


B 


7.0.0 


8.0.0 


Dec 2007 


SP-38 


SP-070746 


0007 


-- 


Clarifications on Online Charging correlation 


C 


8.0.0 


8.1.0 


Jun 2008 


SP-40 


SP-080274 


0008 


— 


Implication on Online Charging System (OCS) description for EPC 
Charging 


B 


8.1.0 


8.2.0 


2009-01 










Editorial correction to preceding entry in history box; 

LTE logo replaces GSM logo; 

Keywords revised; 

Copyright frame updated to current model 




8.2.0 


8.2.1 



ETSI 



3GPP TS 32.296 version 8.2.1 Release 8 



79 



ETSI TS 132 296 V8.2.1 (2009-01) 



History 



Document history 


V8.2.1 


January 2009 


Publication 



























ETSI 



